Subject: [dmarc-ietf] IETF Mailing Lists and DMARC

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Nov 2016 10:00:35 -0600

So if someone send a email with a bad signature to an IETF list from a domain that has a reject policy, and the IETF server forwards it to my email email provider, my email provider rejects it. Now the IETF email server counts that as a bounce. Too many bounces in a row and the IETF server unsubscribes me from the list. 

This does not seem OK that anyone can trivially send some SPAM and get me unsubscribed. 

What's the right advice on how the IETF server should be run?

Now to a more detailed problem - Jana sends lots of email to the quic list. I don't get any of them. It appears that my email server (run by rackspace) rejects them with an 

Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for google.com (G15)

If Jana sends the email directly to me, it works. This seems to point at the IETF server is doing something that breaks signature in Jana email. 

I realize this is not the "debug your email" list, but I have no idea where is the right place to ask about this so I sent it here. Sorry. 

Can anyone tell me how their DMARC system views the emails from Jana to the [email-masked] list ?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Nov 2016 15:00:35 -0400

Cullen Jennings <[email-masked]> wrote:
    > So if someone send a email with a bad signature to an IETF list from a
    > domain that has a reject policy, and the IETF server forwards it to my
    > email email provider, my email provider rejects it. Now the IETF email
    > server counts that as a bounce. Too many bounces in a row and the IETF
    > server unsubscribes me from the list.

    > This does not seem OK that anyone can trivially send some SPAM and get

yeah, that's a real problem isn't it.

After nearly three years of yelling about this problem, we are not even close
to consensus that it's a problem, with many people suggesting that IETF mailing
list software should just munge headers.

DMARC WG was supposedly designing a solution. I don't know where that is.

My take is that IETF mailing list software should reject email from p=reject
senders, since that's their stated policy.

The original threads include:
    https://www.ietf.org/mail-archive/web/ietf/current/msg99659.html

    > Now to a more detailed problem - Jana sends lots of email to the quic
    > list. I don't get any of them. It appears that my email server (run by
    > rackspace) rejects them with an

    > If Jana sends the email directly to me, it works. This seems to point
    > at the IETF server is doing something that breaks signature in Jana
    > email.

Jana needs to stop sending from google.com.

Their policy is that not to forward, so sad to lose all the google.com
contributors.... we really shouldn't violate their stated policy.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Nov 2016 15:12:30 -0400

FWIW, I use Google For Work (or whatever it's called this week) and it
doesn't automatically add DMARC headers--that's something that you
have to configure, apparently.   So while I think that gmail.com is
probably a lost cause, if your org is using GfW, you don't have to use
DMARC.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Nov 2016 21:17:52 +0200

> On 2 Nov 2016, at 21:12, Ted Lemon <[email-masked]> wrote:
> 

Actually there’s no issue with @gmail.com.  The problem is only with @google.com

Yoav

---

From: Hector Santos <[email-masked]>
Date: Wed, 02 Nov 2016 16:05:14 -0400

Since its inception, this has been the "Achilles' heel" of DKIM 
without a Signature Policy Authorization framework.  i.e. authorizing 
3rd party mail processors, such as a list manager/server or could 
bring the integrity and/or resign the mail as a 3rd party.

The IETF abandoned the proposed standard ADSP RFC (and hence any 
add-on extension work like ATPS) and replaced it with an informative 
DMARC RFC described as a "Super ADSP" without resolving the 3rd party 
authorization problem.

ATPS was the original proposed standard to authorize the first party 
signature and combined with ADSP extension ATPS, it covered the Third 
Party Signature authorization.

ADSP/ATPS actually works very well. Its been in production for a 
number of years. I have "ietf.org" as a 3rd party signer assigned to 
my ATPS records in DNS.  Supportive receivers can then see that I 
authorize ietf.org to sign my IETF submissions as my receivers do when 
I get a copy.   My ADSP record for isdg.net is:

dkim=all; atps=y; 
asl=ietf.org,beta.winserver.com,santronics.com,isdg.net,winserver.com,megabytecof
fee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;"

The asl list contains my small list of authorized list servers plus 
other 3rd party associates.  For the larger "registered" list, the 
"atps=" says to lookup the ATPS record the signer domain in the 
author's zone.  It works very well.  This wizards helps illustrates 
how records are created updated for the DMARC record:

     http://www.winserver.com/public/wcdmarc/default.wct

However, this solution requires a "Registration Of 3rd party Domains" 
solution, i.e. you have to learn/teach your personal network of email 
domains and registered them somehow for others to lookup query and 
many feel this won't scale.  It won't for some, it will for others.

Now there is the ARC effort that could help resolve the problem, iff 
everyone supports it. IMO, it appears complex (doc is very verbose). I 
believe it has RFC5222 overhead related code changes.  If you have an 
API ready for it, it should help.  While receivers still need to 
support it, not all receivers use the same API base code.

I was not happy when a big investment was lost when the IETF abandoned 
(incorrect in my opinion) the ADSP work in particular when DMARC 
effectively replaced ADSP, literally described as a "Super ADSP" and 
it didn't offer any 3rd party policy support whatsoever.  So I am not 
too eager to jump on more IETF DKIM, including ARC, related work. 
DMARC is not complete. Its not even a proposed standard. Lots of work 
still needs to be done but I'm sure that RFC status can change when 
desired by the key cogs.  All I would like to see is for DMARC to 
begin offering 3rd party policy models with known solutions that 
include simple DNS lookup like ADSP/ATPS offered.  It shouldn't be 
limited to just ARC.

That said, the only other current way to resolve this with DMARC is to 
relax your policy to "p=none"

By making it "p=reject" all DMARC compatible receivers are designed to 
reject it when its signed by 3rd party signers and/or the original 
mail integrity, hence 1st party signature, is broken.

-- 
HLS

On 11/2/2016 12:00 PM, Cullen Jennings wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Nov 2016 13:23:11 -0700

On 11/2/2016 1:05 PM, Hector Santos wrote:
> Since its inception, this has been the "Achilles' heel" of DKIM without
> a Signature

The issue, here, is with features added by DMARC.  As such, the problem 
has nothing to do with DKIM.

DKIM does not present any problems, with respect to retaining the 
rfc5322.From field contents.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brandon Long <[email-masked]>
Date: Wed, 2 Nov 2016 14:58:31 -0700

With the understanding that my email is unlikely to be received by some of
those having issues...

Let us assume that those who specify p=REJECT have a good reason for doing
so, and that after 2-3 years, they are unlikely to change back.

Let us also assume that the members of these organizations who are
participating in IETF may or may not have any power over whether their
admins have decided to be p=REJECT.

And let us assume that we want these folks to participate in IETF.

I will assume that if you're not willing to stipulate to the above, then
you don't actually want a solution.

We are then left with only moving forward.

If this is a problem for you as a receiver, you can choose to attempt to
whitelist the ietf mailing list mail from DMARC enforcement.  You may not
be able to do so, just like the sender may not be able to change their
organizations DMARC record.

The middle man, ietf, can work around this today.  They need to run a new
enough version of mailman and enable one of the workarounds.  For mailman,
this means munging the mail, usually the From header.  It's not pretty, but
it works, it works now, and it will work for everyone.  The difference is
mostly cosmetic, though depending on your mail client, there may be other
downsides.  And it may violate RFC 5322.

I don't think this is possible with mailman, but theoretically it is also
possible for a mailing list to pass the message through without breaking
the DKIM signature.  This means no footers and no subject tags.  Which of
these a list would choose is probably dependent on the list members.

mailman should also know how to tell the difference between a message
specific policy bounce, and particular DMARC bounces, and should apply
different heuristics to handling them.  I have no idea if that existing in
any version of mailman or is a planned feature.

There is a proposed standard, ARC, that would allow mail receivers to do
more intelligent whitelisting.  It's not ready yet.

It is unfortunate that these types of choices have to be made.

Brandon

On Wed, Nov 2, 2016 at 12:00 PM, Michael Richardson <[email-masked]>
wrote:

>     > This does not seem OK that anyone can trivially send some SPAM and
> get
>     > me unsubscribed.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Nov 2016 16:00:36 -0600

> On Nov 2, 2016, at 1:00 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

My apologies for not checking the archives. I did try but I downloaded a mbox file from one of the IETF mail archive tools that when I importated that into mail.crapp just turned out not to really be a valid mbox file and just turned into one email - anyways, I digress about our broken tools. 

So how do we get this fixed ? Has someone talked to the IESG about this? Right now as a chair, I am making consensus calls that are probably ignoring any emails from people from google.com - and other - because I am not getting their email. That seems like a serious process problem.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Nov 2016 16:13:59 -0600

Agree with your assumptions ( and the later point that receiving person can't controls what their admins do any more than sender can control what their admins do)

But there are two failure modes for something like this 

1) sender knows their email was not received 

2) email was not received by a bunch of people and neither the sender nor receiver knows that

The second failure mode is much worse than the first. 

> On Nov 2, 2016, at 3:58 PM, Brandon Long <[email-masked]> wrote:
> 
> With the understanding that my email is unlikely to be received by some of those having issues...
> 
> Let us assume that those who specify p=REJECT have a good reason for doing so, and that after 2-3 years, they are unlikely to change back.
> 
> Let us also assume that the members of these organizations who are participating in IETF may or may not have any power over whether their admins have decided to be p=REJECT.
> 
> I will assume that if you're not willing to stipulate to the above, then you don't actually want a solution.
> 
> If this is a problem for you as a receiver, you can choose to attempt to whitelist the ietf mailing list mail from DMARC enforcement.  You may not be able to do so, just like the sender may not be able to change their organizations DMARC record.
> 
> The middle man, ietf, can work around this today.  They need to run a new enough version of mailman and enable one of the workarounds.  For mailman, this means munging the mail, usually the From header.  It's not pretty, but it works, it works now, and it will work for everyone.  The difference is mostly cosmetic, though depending on your mail client, there may be other downsides.  And it may violate RFC 5322.
> 
> I don't think this is possible with mailman, but theoretically it is also possible for a mailing list to pass the message through without breaking the DKIM signature.  This means no footers and no subject tags.  Which of these a list would choose is probably dependent on the list members.
> 
> mailman should also know how to tell the difference between a message specific policy bounce, and particular DMARC bounces, and should apply different heuristics to handling them.  I have no idea if that existing in any version of mailman or is a planned feature.
> 
> There is a proposed standard, ARC, that would allow mail receivers to do more intelligent whitelisting.  It's not ready yet.
> 
> On Wed, Nov 2, 2016 at 12:00 PM, Michael Richardson <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Nov 2016 11:19:52 +1300

> And let us assume that we want these folks to participate in IETF.

Let me stop you right there. Yes, we want everybody to be free to
participate in the IETF, and presumably those people want to participate
in the IETF. But participants have to be able to use the tools that the
IETF has chosen, which includes mailing lists. That's always been true.
(In 1992, when I started in the IETF, it meant knowing how to subscribe
to a majordomo list. Today, subscribing is a bit easier, but it means
avoiding the DMARC trap.)

So such participants need to use an email sending address that works
with IETF mailing lists.

yahoo.com and google.com don't work properly with IETF mailing lists.
Fortunately, very fine alternatives are available, such as gmail.com.
(gmail's spam learning is even smart enough to work around p=reject,
as it did for this very message that I'm replying too.)

I think Michael Richardson made a very valid point. If our mailing
list software detects a sender whose domain has p=reject, we *know*
that the forwarded message will fail DMARC validation. So there's a
strong case for rejecting the message immediately, so that the sender
can be told about the problem and can choose a different sending address.
Presumably, we'd only need to do this until ARC is deployable.

> downsides.  And it may violate RFC 5322.

No, it's actually not cosmetic, for reasons that Dave Crocker pointed out.

Regards
   Brian

---

From: "John Levine" <[email-masked]>
Date: 2 Nov 2016 22:34:07 -0000

In article <CAPt1N1=xuj7E66V=[email-masked]> you write:
>doesn't automatically add DMARC headers--

Is it too much to ask that anyone who wants to tell us how to deal
with DMARC should at least read RFC 7489 so he knows how DMARC works?

R's,
John

Helpful tip: There's no such thing as a DMARC header.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Nov 2016 18:46:11 -0400

Yes, it is too much.   I could care less how DMARC works, in the sense
that it clearly _doesn't_ work.   Knowing how it works is not my
problem, and is not the secretariat's problem.   Making IETF mailing
lists work is the secretariat's problem (not mine anymore).
Belittling people who are arguing that a long-standing problem needs
to be fixed is not appropriate.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Nov 2016 15:51:11 -0700

On 11/2/2016 2:58 PM, Brandon Long wrote:
> The difference is mostly cosmetic, though depending on your mail client,
> there may be other downsides.  And it may violate RFC 5322.

Brandon,

You know that I know that the attacks that generated the use of DMARC, 
which is causing the current situation, are serious.  I'm mentioning 
that here to make sure the context for what follows is clear...

Email is communication between an author and one or more recipients.

Everything in between them is 'overhead'.  The overhead functions need 
to be careful to avoid cavalierly reducing the utility of email, even as 
the changes are meant to aid in the use of email.

Identification of the author and recipients is meaningful to them. 
That's not 'cosmetic'.

And software tools employed by users take advantage of this 
identification, for searching and for organizing.

In a highly diverse world, one of the problems of being a very major 
player is that it becomes far too easy not to see all the diversity or 
to appreciate its import to others. After all, most of that diversity is 
seen as such a tiny percentage of the activity. This is the essence of 
ethnocentrism.

Changing the contents of the rfc5322.From field is changing basic 
statements about authorship.

Perhaps there's no practical choice right now, but please let's not be 
cavalier about its import.

d/
-- 

   Dave Crocker

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 2 Nov 2016 19:23:57 -0400

> more intelligent whitelisting.  It's not ready yet.

There is a third option --- which is that if you want to participate
on certain mailing lists, you have to use a non-DMARC e-mail address.
There are people with google.com addresses that need to use non-Google
addresses in order to participate on the Linux Kernel Mailing List.

On Wed, Nov 02, 2016 at 04:00:36PM -0600, Cullen Jennings wrote:
> 
> So how do we get this fixed ? Has someone talked to the IESG about
> this? Right now as a chair, I am making consensus calls that are
> probably ignoring any emails from people from google.com - and other
> - because I am not getting their email. That seems like a serious
> process problem.

I would expect that most folks at Google.com who need to interact with
external communities are painfully aware of the DMARC brain-damage,
and at least with respect to the Googlers who work on the Linux
kernel, so it shouldn't be coming as a surprise.

I would expect that it would easy to determine how many who are on
DMARC-hobbled domains on the IETF working gorup mailing lists, and it
should be easy to create tools to send last-call announcements to
those people to at least solve the process problem.

But given that at the IETF attendees represent themselves, and not
their companies, if it means that people at certain companies need to
get alternate e-mail arrangements, I don't think that's a fatal issue.
It certainly hasn't bothered the LKML administrators, which has a
similar "we're all engieners, not corporate representatives" ethos.

Cheers,

						- Ted

---

From: Terry Zink <[email-masked]>
Date: Thu, 3 Nov 2016 00:36:47 +0000

>> There is a proposed standard, ARC, that would allow mail receivers to 
>> do more intelligent whitelisting.  It's not ready yet.

> There is a third option --- which is that if you want to participate on certain 
> mailing lists, you have to use a non-DMARC e-mail address. There are people 
> with google.com addresses that need to use non-Google addresses in order to 
> participate on the Linux Kernel Mailing List.

I've seen comments that people who were on Yahoo can fortunately go to Gmail. What happens when Gmail publishes a p=reject like they said they were going to (even if the timeline is delayed), per https://wordtothewise.com/2015/10/dmarc-news-gmail-preject-and-arc/?

Perhaps people can go to Outlook.com? What happens if they go to DMARC p=reject? Everyone can go an sign up for yet another domain?

That just kicks the can down the road, but eventually that can will take no more kicks.

---

From: "John Levine" <[email-masked]>
Date: 3 Nov 2016 03:12:13 -0000

>I've seen comments that people who were on Yahoo can fortunately go to Gmail. What happens when Gmail publishes a
>p=reject like they said they were going to (even if the timeline is delayed), per
>https://wordtothewise.com/2015/10/dmarc-news-gmail-preject-and-arc/?

They have said multiple times that they won't do so until ARC is up
and working.  If they're lying, well, we're all schrod.

>That just kicks the can down the road, but eventually that can will take no more kicks.

Indeed.  We look forward to hotmail/outlook implementing ARC so your
users can resume using mailing lists the way they have for 30 years or
more.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 Nov 2016 03:30:31 -0000

>to be fixed is not appropriate.

We all agree that the problem needs to be fixed, but many of us
believe we have a duty to try to understand a problem before demanding
"solutions" which would cause at least as many problems as they solve.

>>doesn't automatically add DMARC headers--

You could solve your DMARC problems overnight by switching to a mail
provider that doesn't throw away mailing list mail that you want.
Fastmail would be a good place to look, competent and cheap.

R's,
John

---

From: Benny Pedersen <[email-masked]>
Date: Thu, 03 Nov 2016 10:21:30 +0100

Cullen Jennings skrev den 2016-11-02 23:00:

> probably ignoring any emails from people from google.com - and other -
> because I am not getting their email. That seems like a serious
> process problem.

Authentication-Results: linode.junc.eu; dmarc=none header.from=iii.ca
Authentication-Results: linode.junc.eu;
	dkim=pass (1024-bit key; secure) header.d=ietf.org header.i=@ietf.org 
header.b=RihtPNGu;
	dkim-atps=neutral

there is no problem as long no one breaks dkim

try dkim sign iii.ca

if i get dmarc pass back here its working as designed, but if its dmarc 
fail, ietf.org breaks dkim

this is so to say, you should whitelist maillist that breaks dkim so you 
never reject it

---

From: Benny Pedersen <[email-masked]>
Date: Thu, 03 Nov 2016 10:30:14 +0100

> there is no problem as long no one breaks dkim

Authentication-Results: linode.junc.eu; dmarc=none header.from=junc.eu
Authentication-Results: linode.junc.eu;
	dkim=pass (1024-bit key; secure) header.d=ietf.org header.i=@ietf.org 
header.b=bXpPFfNS;
	dkim=fail reason="signature verification failed" (1024-bit key; secure) 
header.d=junc.eu header.i=@junc.eu header.b=J+BeXpkF;
	dkim-atps=neutral

sure breaks dkim signed mails :(

---

From: Benny Pedersen <[email-masked]>
Date: Thu, 03 Nov 2016 12:30:42 +0100

> fee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;"

Authentication-Results: linode.junc.eu; dmarc=none header.from=isdg.net
Authentication-Results: linode.junc.eu;
	dkim=pass (1024-bit key; secure) header.d=ietf.org header.i=@ietf.org 
header.b=vqpaROA9;
	dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isdg.net header.i=@isdg.net header.b=twhXt8L/;
	dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=beta.winserver.com header.i=@beta.winserver.com 
header.b=ubq9bnhD;
	dkim-atps=neutral

so it works ?

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 3 Nov 2016 09:49:09 -0400

On Thu, Nov 03, 2016 at 12:36:47AM +0000, Terry Zink wrote:
> I've seen comments that people who were on Yahoo can fortunately go
> to Gmail. What happens when Gmail publishes a p=reject like they
> said they were going to (even if the timeline is delayed), per
> Perhaps people can go to Outlook.com? What happens if they go to
> DMARC p=reject? Everyone can go an sign up for yet another domain?
> 

And then developers can move to fastmail.fm; there are quite a few
mail providers, after all.  And I would expect market forces, combined
with mail providers who aren't trying to send official bills to
consumers that can be easily phished from the same domain as their
customers, such that there will probably be at least one mail provider
that will meet the need of developers and other people who need
traditional mailing lists as they have been implemented for decades.

Alternatively, hopefully ARC will become ready before this is an
issue.  At least a few of the major mail providers have said they
won't enable p=reject until ARC has had a chance to be deployed,
probably because they don't want to have a wholesale (or high profile)
defections from their mail service to providers such as fastmail.fm.

Regards,

						- Ted

---

From: Benny Pedersen <[email-masked]>
Date: Thu, 03 Nov 2016 16:20:16 +0100

> users can resume using mailing lists the way they have for 30 years or

waiting for ARC to solve something that is only a problem on maillists 
that break DKIM, whats next ?

i see no problem on postfix maillist with dmarc pass, so why have others 
choiced a route of fails ?

limit opendkim to only verify last signer could be a option, if last 
signer signs all mails, atleast dkim pass fron every mail here, but i 
dont like that route

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Nov 2016 08:30:47 -0700

> signer signs all mails, atleast dkim pass fron every mail here, but i

this would have no effect on dmarc analysis, other than perhaps 
increasing the rate of failures.

again, the issue is with dmarc.  dkim is, at best, a secondary issue.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Nov 2016 11:53:42 -0400

On 11/3/2016 7:30 AM, Benny Pedersen wrote:
>      dkim=pass (1024-bit key; secure) header.d=ietf.org
> header.i=@ietf.org header.b=vqpaROA9;

yes.

So, my original isdg.net message was submitted to my 
beta.winserver.com submission server. It was DKIM signed 
(d=beta.winserver.com) which then gets routed to my isdg.net machine, 
signed again (d=isdg.net) and sent to ietf.org.

The ietf.org list manager destroys my submission integrity by changing 
the subject line, adds a footer, etc, as most list systems has done 
for many years, thus destroying the first two DKIM signatures.

The DKIM compatible LIST server then properly resigns with d=ietf.org 
as we want all list servers to do when they destroy data as long as 
the original signatures were valid before it does so (but I doubt the 
IETF list server has that logic). It just blindly resigns and begins 
to distribute the mail.

Now it gets to a list downlink receiver with ADSP/ATPS support. The 
receiver sees at least one valid signature, d=ietf.org and checks the 
isdg.net author domain ADSP/ATPS record to see if ietf.org is authorized.

If ietf.org was not in the short asl= list, a ATPS record lookup is 
done for in the author-domain zone:

      atps-hash("ietf.org").author-domain

yes, it works very well.

The concern has always been how do you "learn" your personal community 
of "authorized" 3rd party domains who are allowed to sign on your 
author domain behalf.  We (or at least I) have called that the 
"registration" problem.  So it has a scale issue, but I think it 
definitely works for the small to mid size individual and/or 
organization which is the majority of the market place.

I would like to see adding support to the DMARC record for ATPS 
support, i.e. "atps=" and possible also an option for a short 
"asl=domain list."

ATPS was an add-on for the then "proposed standard" but not abandoned 
ADSP proposal.  DMARC had effectively replaced "ADSP" but oddly it 
decided to not deal with the 3rd party signer designs leaving us in 
limbo for many years and hence the problem you are seeing today.

I added ATPS support to my DMARC implementation, so my DMARC record has:

v=DMARC1; p=none; atps=y; rua=mailto:[email-masked]; 
ruf=mailto:[email-masked];"

with the "atps=y" tag and I can attest that after a few years, there 
is no DMARC processor breakage that I am aware of using the "foreign" 
extension tag as DMARC allows per specification.

-- 
HLS

---

From: Terry Zink <[email-masked]>
Date: Thu, 3 Nov 2016 16:30:23 +0000

>> I've seen comments that people who were on Yahoo can fortunately go to 
>> Gmail. What happens when Gmail publishes a p=reject like they said they 
>> were going to?

> They have said multiple times that they won't do so until ARC is up and working.  If they're lying, well, we're all schrod.

This makes it possible for Gmail to go to p=reject and say to others "Hey, just deploy ARC." Theoretically that will work, but in practice I have my doubts because:

1. It requires all the list servers out there to deploy it, and getting people to upgrade software is non-trivial
2. It requires email receivers to validate ARC. Even if a List Server deploys it, it won't make a different unless we have critical mass of receivers adopting it

So, certainly Google + AOL + Yahoo (?) + Microsoft implementing ARC is great, and they have a lot of mailboxes, but it's unclear that their coverage is broad enough. I think we will be in a hybrid state for a long time wherein we will be supporting multiple solutions - (1) ARC for the long term, and (2) skipping DMARC enforcement for known mailing lists.

--Terry

---

From: Terry Zink <[email-masked]>
Date: Thu, 3 Nov 2016 17:30:20 +0000

>> Perhaps people can go to Outlook.com? What happens if they go to DMARC 
>> p=reject? Everyone can go an sign up for yet another domain?
>> 

> And then developers can move to fastmail.fm; there are quite a few mail providers, after all.  
> And I would expect market forces, combined with mail providers who aren't trying to send 
> official bills to consumers that can be easily phished from the same domain as their customers,
> such that there will probably be at least one mail provider that will meet the need of developers 
> and other people who need traditional mailing lists as they have been implemented for decades.

The average Internet user doesn't understand DMARC. The average person on an Internet mailing list doesn't understand DMARC either, and even the average tech person on a mailing list doesn't understand DMARC. All they know is that their mailing list doesn't work, or that they have been unsubscribed. Only people who work on DMARC understand DMARC.

Asking the average person to switch their email address just so that they can participate in mailing lists isn't a solution.

--Terry

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 3 Nov 2016 13:56:10 -0400

On Thu, Nov 3, 2016 at 1:30 PM, Terry Zink <[email-masked]>
wrote:

> The average Internet user doesn't understand DMARC. The average person on
> an Internet mailing list doesn't understand DMARC either, and even the
> average tech person on a mailing list doesn't understand DMARC. All they
> know is that their mailing list doesn't work, or that they have been
> unsubscribed. Only people who work on DMARC understand DMARC.
>
> Asking the average person to switch their email address just so that they
> can participate in mailing lists isn't a solution.
>

Three thumbs up on the last sentiment above - could you imagine saying to
someone that you need to switch phone providers in order to reach certain
recipients? And while my current use of gmail allows me to more or less get
around DMARC list problems (although I need to check my incoming spam
folder at least daily since mailing list DMARC failures send legitimate
emails there), there’s no guarantee how long that will continue.

And regarding Terry's previous paragraph, while I’m by no means an expert
on DMARC (or mailman for that matter), a bit of googling tells me that
there are more recent versions of mailman than what the IETF is currently
using that support DMARC mitigation. See, for example,
http://www.spamresource.com/2016/09/dmarc-support-in-mailman.html .

Cheers,
Andy

---

From: Steve Atkins <[email-masked]>
Date: Thu, 3 Nov 2016 11:06:58 -0700

> On Nov 3, 2016, at 10:56 AM, Andrew G. Malis <[email-masked]> wrote:
> 
> 
> On Thu, Nov 3, 2016 at 1:30 PM, Terry Zink <[email-masked]> wrote:
> Three thumbs up on the last sentiment above - could you imagine saying to someone that you need to switch phone providers in order to reach certain recipients? And while my current use of gmail allows me to more or less get around DMARC list problems (although I need to check my incoming spam folder at least daily since mailing list DMARC failures send legitimate emails there), there’s no guarantee how long that will continue.
> 
> And regarding Terry's previous paragraph, while I’m by no means an expert on DMARC (or mailman for that matter), a bit of googling tells me that there are more recent versions of mailman than what the IETF is currently using that support DMARC mitigation. See, for example, http://www.spamresource.com/2016/09/dmarc-support-in-mailman.html .

"Mitigating the effects of the DMARC reject policy are difficult. All known mitigation techniques break some user expectations and/or degrade the user experience. Still, it's incumbent on the Mailman developers to try to reduce the pain our users feel, and to provide some options for site and list administrators who find themselves caught in the middle."

[email-masked], of all lists, is not one whose administrators are "caught in the middle".

Cheers,
  Steve

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 3 Nov 2016 14:24:43 -0400

Hi Steve!

The site goes on to say:

"If you don't take any action here, you're leaving a subset of your
potential subscribers out in the cold. Making them second class citizens,
unable to participate in the mailing lists you're hosting. Be kind, and
don't beat up Yahoo users because of a domain policy that Yahoo choose to
implement (and that Yahoo user is stuck dealing with).”

I certainly agree with that sentiment. And it’s not the DMARC WG that's
responsible for IETF email list support, it’s the admin staff at AMS that
are the ones “caught in the middle”.

Cheers,
Andy

On Thu, Nov 3, 2016 at 2:06 PM, Steve Atkins <[email-masked]>
wrote:

> > The average Internet user doesn't understand DMARC. The average person
> on an Internet mailing list doesn't understand DMARC either, and even the
> > Asking the average person to switch their email address just so that
> they can participate in mailing lists isn't a solution.
> >
> > Three thumbs up on the last sentiment above - could you imagine saying
> to someone that you need to switch phone providers in order to reach
> certain recipients? And while my current use of gmail allows me to more or
> less get around DMARC list problems (although I need to check my incoming
> spam folder at least daily since mailing list DMARC failures send
> legitimate emails there), there’s no guarantee how long that will continue.
> >
> > And regarding Terry's previous paragraph, while I’m by no means an
> expert on DMARC (or mailman for that matter), a bit of googling tells me
> that there are more recent versions of mailman than what the IETF is
> currently using that support DMARC mitigation. See, for example,
> "Mitigating the effects of the DMARC reject policy are difficult. All
> known mitigation techniques break some user expectations and/or degrade the
> user experience. Still, it's incumbent on the Mailman developers to try to
> reduce the pain our users feel, and to provide some options for site and
> list administrators who find themselves caught in the middle."
>

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 3 Nov 2016 20:32:14 +0100

On Thu 03/Nov/2016 16:53:42 +0100 Hector Santos wrote:
>
> The ietf.org list manager destroys my submission integrity by changing the
> subject line, adds a footer, etc, as most list systems has done for many years,
> thus destroying the first two DKIM signatures.

That's the culprit, of course.  Note that MLM does not change the subject if it 
already contains the tag.  However, it adds a footer even if one exists.  Since 
we talk of mailing list software capabilities, can't that be amended?

Then, a MLM can require that p=reject domains submit "camera-ready" posts. 
Senders comply before signing, if they spot a ML among recipients.  Isn't that 
solution simpler and more straightforward than ARC?  It's also simpler than 
weak signatures.  Was it aired, yet?

Ale

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 3 Nov 2016 18:03:26 -0400

On Thu, Nov 03, 2016 at 05:30:20PM +0000, Terry Zink wrote:
> 
> The average Internet user doesn't understand DMARC. The average
> person on an Internet mailing list doesn't understand DMARC either,
> and even the average tech person on a mailing list doesn't
> understand DMARC. All they know is that their mailing list doesn't
> work, or that they have been unsubscribed. Only people who work on
> DMARC understand DMARC.

IETF contributers aren't exactly "the average Internet user"..... (Or
are Linux Kernel contributors, since kernel.org is one of the other
lists where your use of a domain that uses DMARC not considered the
mailing list administrators' problem; and degrading everyone else's
mailing list experience just for 'the average Internet user' is
something they have chosen not to do.)

> they can participate in mailing lists isn't a solution.

It certainly isn't a long term solution; I think we all hope ARC can
get successfully deployed soon.

						- Ted

---

From: Brandon Long <[email-masked]>
Date: Thu, 3 Nov 2016 15:39:22 -0700

> Presumably, we'd only need to do this until ARC is deployable.

If enforcement of DMARC was universal (or nearly so), sure.  Except, it's
not.
As you said, Gmail didn't enforce it in this instance.

Rejecting the messages is definitely an option.  As stated down thread, I
wouldn't
think it's the best choice for the members.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Thu, 3 Nov 2016 16:03:45 -0700

On Wed, Nov 2, 2016 at 3:51 PM, Dave Crocker <[email-masked]> wrote:

> which is causing the current situation, are serious.  I'm mentioning that
> here to make sure the context for what follows is clear...
>
> Everything in between them is 'overhead'.  The overhead functions need to
> be careful to avoid cavalierly reducing the utility of email, even as the
> changes are meant to aid in the use of email.
>
> Identification of the author and recipients is meaningful to them. That's
> not 'cosmetic'.
>

Including Gmail, which doesn't handle this workaround well, either.

> player is that it becomes far too easy not to see all the diversity or to
> appreciate its import to others. After all, most of that diversity is seen
> as such a tiny percentage of the activity. This is the essence of
> ethnocentrism.
>

I think technical fans of email perhaps attach more import to the
rfc5322.from field than does the average user.  Certainly, downsides
exist.  That said, facebook notifications today all come from the same
per-user address, with the actual commenter as just the display name.
Various forum software, email ticketing software, the email notifications
from various web based messaging systems, they all fail to apply authorship
in how you say.

Yes, mailing lists have existed in this form for some time, and they are a
good and vital system, and the downsides are real.

Note also that I imagine that mailing list software which supports EAI
messages might also need to munge the From header to downgrade the message
for delivery to non-EAI enabled receivers.

I'm not sure if my comment was heard in the recent ARC round table, where
folks were questioning the overall complexity of ARC, but I'm fairly
serious in saying that all of our discussions on work arounds and technical
methods for trying to make DMARC work with mailing lists, and from header
munging is by far the simplest.  No trust/reputation systems, no manual
whitelisting, no "magic sauce", no new software to be installed by
receivers.

ARC will add greatly to the size of mail headers, which some folks on
mailop still think should be tiny and talk about automatically marking
large headers as spam.

ARC will add greatly to the privacy concerns which were raised last week on
the DKIM IETF list, where now not only is a message have attestation of
origin, but that attestation will survive some amount of
forwarding/modification, and the path it took will also be attested to.

ARC will require new software to be installed by mailing list providers and
any receivers who implement DMARC.  Even after being installed, there is
still more work in order to allow the mailing list messages through.

Brandon

---

From: Franck Martin <[email-masked]>
Date: Thu, 3 Nov 2016 19:00:43 -0500 (CDT)

> From: "Brandon Long" <[email-masked]>
> To: "Brian E Carpenter" <[email-masked]>
> Cc: "Michael Richardson" <[email-masked]>, [email-masked], "IETF"
> <[email-masked]>, "Cullen Jennings" <[email-masked]>
> Sent: Thursday, November 3, 2016 3:39:22 PM
> Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC

> On Wed, Nov 2, 2016 at 3:19 PM, Brian E Carpenter < [email-masked]
> > wrote:

>> Fortunately, very fine alternatives are available, such as gmail.com .

> If enforcement of DMARC was universal (or nearly so), sure. Except, it's not.

> think it's the best choice for the members.

Politics of exclusion are easy but usually do not go far... us vs them is never a long term option. 

but I'd like to point to a new problem surfacing as security is shifting with DMARC: impersonation on mailing lists. 

Several large lists have been recently caught by email impersonating list members. 

Was it successful enough for the miscreant? Will we see more in the future? 

Do lists need to check DMARC on incoming mail and apply policy? Do they need to do more than DMARC and authenticate the poster?

---

From: Hector Santos <[email-masked]>
Date: Fri, 04 Nov 2016 08:21:41 -0400

> can be told about the problem and can choose a different sending address.

I had it in my 2006 DSAP proposal for MLM guidelines:

   http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3

The term DMARC can be swapped in the section since its really about a 
general DKIM+POLICY and it doesn't matter if it was SSP, ADSP, DSAP or 
DMARC:

    3.3.  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with DKIM
    and DMARC operations, SHOULD adhere to the following guidelines:

    Subscription Controls

       MLS subscription processes should perform a DMARC check to
       determine if a subscribing email domain DMARC policy is restrictive
       in regards to mail integrity changes or 3rd party signatures.  The
       MLS SHOULD only allow original domain policies who allow 3rd party
       signatures.

    Message Content Integrity Change

       List Servers which will alter the message content SHOULD only do
       so for original domains with optional DMARC signing practices and
       it should remove the original signature if present.  If the List
       Server is not going to alter the message, it SHOULD NOT remove the
       signature, if present.

Wow! 10 years and we still having this issue! Incredible. :(

But I did add the subscription controls for our ML software.

> Presumably, we'd only need to do this until ARC is deployable.

Can ARC resolve the downlink problem for the non-ARC compliant receivers?

I've always said that the MLM needs to "look up" the practices of the 
Author Domain.  What is its expectation?  Intentions?

If the MLM expects the receivers to do DMARC lookups, why shouldn't 
the MLM do the same prior to accepting a list submission or 
subscriber?   The MLM can also check/detect DMARC related SMTP error 
responses and minimize the erroneous automatic removals from list. 
All this requires MLM software change.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Nov 2016 10:55:19 -0400

--On Thursday, November 03, 2016 14:24 -0400 "Andrew G. Malis"
<[email-masked]> wrote:

>...
>> And regarding Terry's previous paragraph, while I'm by no
means an
>> expert on DMARC (or mailman for that matter), a bit of
>> googling tells me that there are more recent versions of
>> mailman than what the IETF is currently using that support
>> DMARC mitigation. See, for example,
>> http://www.spamresource.com/2016/09/dmarc-support-in-mailman.h
>> tml . Hi Steve!
> 
> The site goes on to say:
> 
> "If you don't take any action here, you're leaving a subset of
> your potential subscribers out in the cold. Making them second
> class citizens, unable to participate in the mailing lists
> you're hosting. Be kind, and don't beat up Yahoo users because
> of a domain policy that Yahoo choose to implement (and that
> Yahoo user is stuck dealing with)."
> 
> I certainly agree with that sentiment. And it's not the
> DMARC WG that's responsible for IETF email list support,
> it's the admin staff at AMS that are the ones "caught in
> the middle".

Andy (and others), 

We are beginning to move away from protocols and toward
philosophy here.  Maybe that is as it should be, so, from the
perspective of someone who probably belongs on John Levine's
list of people who have been thinking about email for a really
long time, some observations.

First, we got here because a small collection of email service
providers got together and developed and deployed a piece of
protocol that, among other things, ignored the implications of
that protocol (or some of configurations that were possible with
it) for mailing lists as we have traditionally understood them.
I don't have any reason to believe it was relevant to their
decisions, but I note that the providers involved all run their
own "groups", "forums", etc., as an alternative to traditional
Internet email-based mailing lists.

Second, there are a number of aspects of our email architecture
that assume users have both a trust relationship with, and some
control over, their email service providers.  There are aspects
of POP3 and IMAP4 that make no sense without that assumption and
many antispam activities and actions would be serious violations
of the standards in the absence of that assumption.  Nothing
prevents a user from agreeing with a provider that, in return
for "free" email service, that provider gets the right to decide
what messages the user can receive or send, to scan messages for
content of interest (e.g., to determine user interests from
advertising purposes), to make unilateral decisions about
whether messages or message trace information should be revealed
to others, and to change the rules after that user is thoroughly
locked in.  

The IETF can't protect users from such agreements and we
probably shouldn't try even if we could.    That doesn't mean I
am willing to agree to that -- I won't and, if I ever decide to
outsource my mail services, it will be to someone to whom I pay
money and from whom I can get an appropriate SLA because free
lunches make me nervous.

One of the things that make the IETF community (and, I assume,
Ted's Linux developer community) different from the general user
community is that the proportion of people with attitudes like
mine is a lot higher than in that general population of Internet
users.  Another is that we get to assume a sufficient level of
clue to at least understand the tradeoffs mentioned above.

So, while "that [random] Yahoo user" has my sympathy, those who
want to participate in, and contribute to, the IETF get a lot
less of it if they can't figure out where to find and how to use
a mail system that conforms to our standards rather than
something made up by a handful of mail providers to serve their
own needs, no matter how many customers/ users/ victims they
have.

Finally, I'd like to suggest people who have been involved in
this debate think about something even if it seems far-fetched.
Suppose some vendors and/or ISPs got together and agreed on an
improvement to IP that would have the side effect of making
things better for their customers but worse for some others.
Would the IETF be scrambling around trying to modify IP to make
the pain for the non-customers somewhat less, perhaps in the
process helping to pressure other vendors and ISPs into
conforming to the "new" protocols?  We've got a partial answer
with ISPs giving preference to some content providers over
others with the "net neutrality" debate, something many of us
have recognized as an abuse of market power fundamentally
inconsistent with network principles, but the differences
between that case and the DMARC one may be less significant than
might appear at first glance.

I'm still looking forward to ARC and any other approaches that
move us forward with solutions to what I assume we all recognize
as a real problem.   But I think we need to be much more
cautious about "solutions" that make Internet mail work less
well as well as ones that mitigate problems in ways that may
retard real solutions.

    john

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Nov 2016 11:21:46 -0400

Forgive me if this isn’t as respectful as it could be, but your rather long dissertation on the problem didn’t actually say what would go wrong if we did something about it.   Is there something missing from the summary I wrote and sent to the mailing list yesterday?

This is an operational issue, not a philosophical issue.   People are trying to get work done, and a problem created by people other than them is preventing them from getting work done.  Worse, it’s doing it in a way that is difficult for third parties to detect, and that has resulted in people unexpectedly and unknowingly not getting email they needed to get.

This is a _really serious problem_.   Arguing that we shouldn’t solve it because we have philosophical issues is silly.   It’s like arguing that we shouldn’t have firewalls, which break IP in exactly the way you described, because they are bad on a philosophical level.   They _are_ bad on a philosophical level.   We, the IETF, are not going to stop people from installing them, because they are _good_ on an ops level.   The idea that we shouldn’t solve problems like this regarding email went out the window when Canter and Siegel came on the scene.

That’s just life.   So if you have a technical reason why fixing this problem is a bad idea, please share it.   And I am always interested in your philosophy.   But I do not think you have made a valid technical argument against the IESG addressing this operational problem.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Nov 2016 11:37:57 -0400

Ted Lemon <[email-masked]> wrote:
    > doesn't automatically add DMARC headers--that's something that you have
    > to configure, apparently.  So while I think that gmail.com is probably
    > a lost cause, if your org is using GfW, you don't have to use DMARC.

Yes, that's true.
google.com (for google employees) apparently does have DMARC enabled.
That's a policy decision they made.

Some places (paypal, I think), moved all their employees to corp.example.com,
so they could DMARC for their official emails, without screwing their
employees' work.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Nov 2016 11:47:21 -0400

Andrew G. Malis <[email-masked]> wrote:
    > certain recipients? And while my current use of gmail allows me to more

yes, we lived through a decade of:
     "This site best viewed in Internet Explorer in 1024 x 768"

(Except that "best" meant, "it won't work otherwise", and this kind of crap
was ubiquitous from many governments.  We fixed the end points, we didn't
work around it with middle box hacks)

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Nov 2016 12:55:56 -0400

Ted,

I started that note before you posted your list of four options
and decided to send it anyway.   I think your list is correct
and, since it apparently wasn't obvious from my comments, prefer
your first option.

The reason for the long note is that I don't accept this as
"just life".  I believe the IETF has an affirmative obligation
to avoid breaking the Internet -- or the protocols it has chosen
to standardize -- and to avoid encouraging those who choose to
do so.  Assuming there is no disagreement that the problem is
real, one implication of that involves a very strong preference
for bringing work to the IETF while it is still at (or before)
the design phase rather than having something half-designed
elsewhere,   deployed, and them brought to the IETF on either as
"standardize this as is because it is deployed" or a "you folks
in the IETF can now straighten out the mess we made by
developing and deploying this without thinking through the
implications".  Given that the problem is real, the IETF of
course has some obligation to take it on in a serious way.
When the breakage is bad enough (and I'm not taking a position
on whether DMARC is) and is the result of an action by a
dominant player or collection of them, I also believe that we
(individually if not in the name of the IETF, have a
professional obligation to initiate or participate in
discussions with appropriate authorities about anticompetitive
and/or monopolistic behavior.

Finally (and here is where I demonstrate that I'm very far out
in the rough), your comment about Canter and Siegel identifies a
different, but to me important, issue.  Suppose we have a
community that as a significant problem with either domestic
animals or humans defecating on the sidewalks.   Obviously one
option is for everyone who lives there or visits to become very
careful about where they step, but that has a number of serious
implications.  Another is to prohibit doing that and to also
have "clean up after your pets and offspring" rules.    However,
carrying around appropriate bags and pick-up instruments is
annoying and experience indicates that, unless those rules are
enforced (as either a matter of law or effective community
outrage), there will still be a lot of s**t on the streets.
That becomes interesting as a social problem because, if a group
of well-meaning people springs up to come around the community
every day and clean up previously-untended messes, any pressure
to punish or otherwise deter those who are responsible for those
messes disappears (and more people may be encouraged to stop
going to the trouble of cleaning up after themselves and their
pets).  On the other hand, if those spontaneous and well-meaning
efforts do not occur, then the pressures within the community to
punish those who cannot be bothered to do the cleaning up rise
until either such measures are taken or the community, including
the non-offenders, are explicitly taxed to provide funding for
claiming up the problem.

There are aspects of the spam problem that are a lot like that.
Many of the significant costs are incurred as soon as the
messages start to cross the Internet.  Solutions that involve
filtering the messages so they cannot be delivered do nothing to
address that problem, nor to impose costs on the message
originators.    Instead, by mitigating the nuisance value of the
spam and the risks to the recipient of whatever comes with the
spam messages, they have the side-effect of reducing the
incentives to find the spammers and punish their behavior in a
serious enough way to deter the practice.  Indeed, if the
spammer's objective is to get a certain number of messages
through, actions that increase the percentage of spam messages
that are blocked near the delivery point may create an incentive
to increase the number of messages sent and hence the burdens on
the network and the costs to those who maintain mail delivery
systems.

Again, I am not suggesting that the IETF (or anyone else) try to
ignore the spam problem.   However, it seems to me that we need
to think a bit more about the whole system, evaluate questions
like how much we are willing to give up for the privacy
advantages of hard-to-trace message origins, and generally be
careful what we wish for.

    best,
    john

--On Friday, November 04, 2016 11:21 -0400 Ted Lemon
<[email-masked]> wrote:

> Forgive me if this isn't as respectful as it could be, but
> your rather long dissertation on the problem didn't actually
> say what would go wrong if we did something about it.   Is
> there something missing from the summary I wrote and sent to
> the mailing list yesterday?
> 
> This is an operational issue, not a philosophical issue.
> People are trying to get work done, and a problem created by
> people other than them is preventing them from getting work
> done.  Worse, it's doing it in a way that is difficult for
> third parties to detect, and that has resulted in people
> unexpectedly and unknowingly not getting email they needed to
> get.
> 
> This is a _really serious problem_.   Arguing that we
> shouldn't solve it because we have philosophical issues is
> silly.   It's like arguing that we shouldn't have
> firewalls, which break IP in exactly the way you described,
> because they are bad on a philosophical level.   They _are_
> bad on a philosophical level.   We, the IETF, are not going to
> stop people from installing them, because they are _good_ on
> an ops level.   The idea that we shouldn't solve problems
> like this regarding email went out the window when Canter and
> Siegel came on the scene.
> 
> That's just life.   So if you have a technical reason why
> fixing this problem is a bad idea, please share it.   And I am
> always interested in your philosophy.   But I do not think you
> have made a valid technical argument against the IESG
> addressing this operational problem.
>

---

From: Terry Zink <[email-masked]>
Date: Fri, 4 Nov 2016 20:21:56 +0000

> I think technical fans of email perhaps attach more import to the rfc5322.from field than
> does the average user.  Certainly, downsides exist.  That said, facebook notifications
> today all come from the same per-user address, with the actual commenter as just the
> display name.  Various forum software, email ticketing software, the email notifications
> from various web based messaging systems, they all fail to apply authorship in how you say.

I think of myself as a technical email guy, but I’m surprised at how much of an average user I am. If I were to get an email from someone (or I guess myself) on this list like this:

From: Terry Zink via IETF-DMARC <[email-masked]>

This already happens from other lists I am on, I don’t think twice about it. I sort of even think “Hey, that works better for me!”

And if there were something like this in other headers that retains the original senders:

Reply-To: [email-masked]
Sender: dmarc <[email-masked]>

Then so much the better, I don’t even notice them unless I hit Reply. As Brandon says, I’ve already been conditioned to look for the same email address, for example I get this from LinkedIn:

From: Example Person (via LinkedIn) <[email-masked]>

I get that some people don’t like how the From: address no longer reflects the “real” sender, but I don’t just use the email address to identify a sender. I use the Display Name, too, and putting someone’s name and the source into the Display Name is helpful.

That doesn’t mean there aren’t better options. But this workaround – at least for me – is not that painful.

--Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Brandon Long
Sent: Thursday, November 3, 2016 4:04 PM
To: Dave Crocker <[email-masked]>
Cc: [email-masked]; IETF <[email-masked]>
Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)

On Wed, Nov 2, 2016 at 3:51 PM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:
On 11/2/2016 2:58 PM, Brandon Long wrote:
The difference is mostly cosmetic, though depending on your mail client,
there may be other downsides.  And it may violate RFC 5322.

Brandon,

You know that I know that the attacks that generated the use of DMARC, which is causing the current situation, are serious.  I'm mentioning that here to make sure the context for what follows is clear...

Everything in between them is 'overhead'.  The overhead functions need to be careful to avoid cavalierly reducing the utility of email, even as the changes are meant to aid in the use of email.

Identification of the author and recipients is meaningful to them. That's not 'cosmetic'.

And software tools employed by users take advantage of this identification, for searching and for organizing.

In a highly diverse world, one of the problems of being a very major player is that it becomes far too easy not to see all the diversity or to appreciate its import to others. After all, most of that diversity is seen as such a tiny percentage of the activity. This is the essence of ethnocentrism.

Changing the contents of the rfc5322.From field is changing basic statements about authorship.

Perhaps there's no practical choice right now, but please let's not be cavalier about its import.

I think technical fans of email perhaps attach more import to the rfc5322.from field than does the average user.  Certainly, downsides exist.  That said, facebook notifications today all come from the same per-user address, with the actual commenter as just the display name.  Various forum software, email ticketing software, the email notifications from various web based messaging systems, they all fail to apply authorship in how you say.

Yes, mailing lists have existed in this form for some time, and they are a good and vital system, and the downsides are real.

Note also that I imagine that mailing list software which supports EAI messages might also need to munge the From header to downgrade the message for delivery to non-EAI enabled receivers.

I'm not sure if my comment was heard in the recent ARC round table, where folks were questioning the overall complexity of ARC, but I'm fairly serious in saying that all of our discussions on work arounds and technical methods for trying to make DMARC work with mailing lists, and from header munging is by far the simplest.  No trust/reputation systems, no manual whitelisting, no "magic sauce", no new software to be installed by receivers.

ARC will add greatly to the size of mail headers, which some folks on mailop still think should be tiny and talk about automatically marking large headers as spam.

ARC will add greatly to the privacy concerns which were raised last week on the DKIM IETF list, where now not only is a message have attestation of origin, but that attestation will survive some amount of forwarding/modification, and the path it took will also be attested to.

ARC will require new software to be installed by mailing list providers and any receivers who implement DMARC.  Even after being installed, there is still more work in order to allow the mailing list messages through.

Brandon

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Nov 2016 17:22:31 -0400

On Nov 4, 2016, at 4:21 PM, Terry Zink <[email-masked]> wrote:
> Reply-To: [email-masked] <mailto:[email-masked]>
> Sender: dmarc <[email-masked] <mailto:[email-masked]>>
> 

I don’t think this is quite right—I think the Reply-To needs to include all of the senders or else every reply will be an off-list reply (would cut down on noise, admittedly).   Otherwise this would be a great solution.   But because of the way it interacts with MUAs, I do not think it would work in a way that doesn’t violate the principle of least surprise.

---

From: Terry Zink <[email-masked]>
Date: Fri, 4 Nov 2016 21:54:33 +0000

If you hit “Reply-All”, at least when I use Gmail, it includes both the From: and the Reply-To using the scheme below (I tested it out just now). In Outlook desktop I have to also copy/paste the From: address (mailing list). It’s not ideal in Outlook desktop, but I can live with it.

In this email discussion, I hit Reply-All and includes Ted on the To:, and [email-masked]<mailto:[email-masked]> and [email-masked]<mailto:[email-masked]> on the cc.

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, November 4, 2016 2:23 PM
To: Terry Zink <[email-masked]>
Cc: [email-masked]; IETF <[email-masked]>
Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)

On Nov 4, 2016, at 4:21 PM, Terry Zink <[email-masked]<mailto:[email-masked]>> wrote:
And if there were something like this in other headers that retains the original senders:

Reply-To: [email-masked]<mailto:[email-masked]>
Sender: dmarc <[email-masked]<mailto:[email-masked]>>

---

From: Steven M Jones <[email-masked]>
Date: Fri, 4 Nov 2016 22:48:52 +0000

A lot of points have been raised (again) in this thread - and I was only
looking at what went to the DMARC WG list, forgetting that of course
somebody would continue/branch the conversation by only using the
ietf@ietf list...

John Klensin highlighted a fundamental issue when he mentioned "the
privacy advantages of hard-to-trace message origins." The
assumption/decision that we want to keep that feature of existing email
protocols - but still try to identify bad actors - is what started us
down the road from SPF, to DomainKeys, to DKIM/SSP/ADSP, to DMARC.

Are we going to revisit that assumption/decision? If not, we'd better
look at how to make DMARC something we can all live with...

Are we going to try and extend DMARC with something like an ATPS that
scales? Is there an intersection of ATPS and ARC that might meet the need?

--S.

---

From: Franck Martin <[email-masked]>
Date: Mon, 7 Nov 2016 13:41:18 -0600 (CST)

The EAI WG found it was fine to remove the obligation to have an email address part in the mandatory RFC5322.From header, leaving only the display part to assert the original author. 

So it seems that "IETF" is not completely in agreement on how to preserve the original author in emails. 

So I think the example showed by Terry is as good as what is in EAI and this is a matter of taste and UI designs, UI design and functions that usually the IETF avoids to deal with... 

From: "Terry Zink" <[email-masked]> 
To: "Ted Lemon" <[email-masked]> 
Cc: [email-masked], "IETF" <[email-masked]> 
Sent: Friday, November 4, 2016 2:54:33 PM 
Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) 

In this email discussion, I hit Reply-All and includes Ted on the To:, and [email-masked] and [email-masked] on the cc. 

On Nov 4, 2016, at 4:21 PM, Terry Zink < [email-masked] > wrote: 

Reply-To: [email-masked] 
Sender: dmarc < [email-masked] >

---

From: Dave Crocker <[email-masked]>
Date: Mon, 7 Nov 2016 14:46:54 -0800

On 11/7/2016 11:41 AM, Franck Martin wrote:
> The EAI WG found it was fine to remove the obligation to have an email
> address part in the mandatory RFC5322.From header, leaving only the
> display part to assert the original author.

We had that relaxed permission for From:, in the original 
From/Sender/Reply-to specification of rfc733, with the requirement that 
there be a Sender: email address.  It looks like we removed it for rfc822.

And while I recall something of the EAI discussion, I'm not recalling 
this permission's being returned.  Nor am I finding it in rfc6854:

      https://tools.ietf.org/html/rfc6854#section-2

So, please point to the formal specification that permits a From: field 
to have no email address.

Absent that, there's the small question about how the EAI group would 
have the authority to make such a major change to such a basic email 
feature...

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 7 Nov 2016 14:54:25 -0800

On 11/4/2016 2:54 PM, Terry Zink wrote:
> If you hit “Reply-All”, at least when I use Gmail, it includes both the
> From: and the Reply-To using the scheme below (I tested it out just
> now). In Outlook desktop I have to also copy/paste the From: address
> (mailing list). It’s not ideal in Outlook desktop, but I can live with it.
>
> In this email discussion, I hit Reply-All and includes Ted on the To:,
> and [email-masked] <mailto:[email-masked]> and [email-masked]
> <mailto:[email-masked]> on the cc.

RFC5322:

> When the "Reply-To:" field is present, it
>    indicates the address(es) to which the author of the message suggests
>    that replies be sent.

and

> In the absence of the "Reply-To:" field,
>    replies SHOULD by default be sent to the mailbox(es) specified in the
>    "From:" field unless otherwise specified by the person composing the
>    reply.

This does not prohibit also sending to the From: address, but it makes 
clear that including the From: address goes against the intent of having 
the Reply-To: field.  So such copying violates the intent of the 
Reply-to field.

That such behavior is common doesn't make it a good choice.

d/

-- 

   Dave Crocker

---

From: [email-masked]
Date: Mon, 07 Nov 2016 15:08:08 -0800 (PST)

> to have no email address.

RFC 6854.

> have the authority to make such a major change to such a basic email

RFC 6854 can speak for itself as to the rationale for allowing no address.

The EAI connection was, as I recall, for use in downgrade formats used to
present EAI messages to non-EAI clients via POP3 and IMAP4.

				Ned

---

From: Franck Martin <[email-masked]>
Date: Mon, 7 Nov 2016 17:23:33 -0600 (CST)

----- Original Message -----
> From: "Dave Crocker" <[email-masked]>
> To: "Franck Martin" <[email-masked]>, "Terry Zink" <[email-masked]>
> Cc: [email-masked], "Ted Lemon" <[email-masked]>, "IETF" <[email-masked]>
> Sent: Monday, November 7, 2016 2:46:54 PM

> to have no email address.

I'm not great at ABNF, so please bear with me. 

My understanding is that RFC proposes the following change:

from =  "From:" mailbox-list CRLF

TO

from = "From:" (mailbox-list / address-list) CRLF

They are defined by:
mailbox-list    =   (mailbox *("," mailbox)) / obs-mbox-list
address-list    =   (address *("," address)) / obs-addr-list

furthermore: 

address         =   mailbox / group
mailbox         =   name-addr / addr-spec
name-addr       =   [display-name] angle-addr
angle-addr      =   [CFWS] "<" addr-spec ">" [CFWS] /
                       obs-angle-addr
group           =   display-name ":" [group-list] ";" [CFWS]
display-name    =   phrase
mailbox-list    =   (mailbox *("," mailbox)) / obs-mbox-list
address-list    =   (address *("," address)) / obs-addr-list
group-list      =   mailbox-list / CFWS / obs-group-list

So if you follow the fact that the new from can contain an address list, and that an address can be either a mailbox or a group and that a group can be 'undisclosed sender:;'

So you could find an email with the following header

From: undisclosed sender:;

and that would be ok as per rfc6854

Note the security consideration in same RFC that "discourages" the use of the group syntax, but as a receiver, I would claim, this increases the level of secret sauce to apply to evaluate an email...

---

From: Dave Crocker <[email-masked]>
Date: Mon, 7 Nov 2016 15:40:56 -0800

>> to have no email address.

That's what I cited, too.  It makes much of allowing the group construct 
(to permit aggregating various forms of the same addressee).

I assume the 'no address' permission is based on the CWFS alternative in:

which the document doesn't explain at all.  Nor does it impose the 
RFC733 fall-back of requiring a Sender: field, with an email address.

If there's something else permitting no addressee, I'm still missing it.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Nov 2016 22:25:29 -0500

(adding the EAI list to the distribution -- there are people who
hang out there who need to see, and check on, this)

--On Monday, November 07, 2016 15:08 -0800
[email-masked] wrote:

>> Absent that, there's the small question about how the EAI
>> group would have the authority to make such a major change to
>> such a basic email feature...
> 

Yes.
IIR, 6854 was written the way it was in order to avoid getting
tangled up with normative dependencies on the EAI specs.
However, I find the combination of its Section 3 ("Applicability
Statement") and Security Considerations rather clear as to both
the motivation and the "don't do this if you don't need to and
especially don't originate a message with this" advice.
"Limited Use" is really very restrictive.
 
The problem (and tradeoff) are as follows:

A message gets delivered and gets as far as a mailstore with a
backward-pointing address that looks like:
  "Non ASCii Name Phrase" <non-ascii-local-part@domain-part>

Note that, if the message got that far, the delivery MTA
advertised itself as fully SMTPUTF8-complaint.

Then a POP or IMAP client comes along that does not support
non-ASCII addresses or headers.   Now, there are probably three
plausible choices for the IMAP server (other than just dying a
horrible death):

(a) Trash the message on the theory that any users who would get
themselves into that situation deserve it.  However, remember
the important case is a backward-pointing address and, in the
general case, the delivery server doesn't know what client(s)
the user is going to use (and there might be more than one).

(b) Figure out how to respond to any IMAP request that involves
that message with some flavor of "I have this message for you,
but you can't get it and I can't tell you about it until you
show up with an upgraded client".

(c) Convert "Non ASCii Name Phrase" to encoded words and then do
something unpleasant to the address, of which using group syntax
was by far the least problematic solution anyone could come up
with.  If the Return-path in the  mailstore is the same as the
address in the "From:" and/or "Sender:" header fields, it is
going to be trashed, so a competent IMAP server doing this is
going to figure out how to warn the user and the user, perhaps
after consulting support personnel the first time one of these
happens to her, is going to figure out that doing anything with
the message other than broadly getting its gist is going to
require using an upgraded client.

IIR, these issues are discussed at some length in RFCs 6855-6858.

Now, coming back to the "identification of ... author" problem
and remembering the "Limited Use" bit, if I were designing a
submission server and something reached me with a group name in
the "From:" (or "Sender:") field, I'd probably return it to
whence it came.    I'd probably do the same thing if I were a
relay or delivery server, noting that there is no equivalent to
group syntax in SMTP.   Both are entirely consistent with
Limited Use -- if one uses it in a context in which it makes no
sense or poses a security threat, one refuses to accept it.

If anyone things that needs to be said more clearly in one of
the EAI-related documents and wants to suggest language, I, and
I assume others, anxiously await an I-D.

   john

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2016 22:08:03 -0000

>to have no email address.

RFC 6854 section 2.1 allows the From: addresses to be an address-list.

In RFC 5322 sec 3.4, an adresss-list can be an address, an address can
be a group, and the group-list of addresses in a group is optional.

The example near the bottom of page 2 of RFC 6854, after the second
paragraph of section 1, should make it obvious that this expansion is
not unexpected.

>have the authority to make such a major change to such a basic email 

We did this for the narrow and specific case of delivery time
downgrades described in RFC 6858, when a mail system is EAI compatible
all the way to the POP or IMAP server, but the MUA fetching the mail
isn't.  The POP or IMAP server is allowed to smash the headers into
ASCII that the ASCII-only client can display and one of the options
for a UTF-8 mailbox in a From: or other header is to replace it with
an empty group.

You can ask Barry how much he expects this to affect ASCII mail, since
he wrote 6854.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2016 22:57:30 -0000

In article <[email-masked]> you write:

>The EAI WG found it was fine to remove the obligation to have an email address part in the
>mandatory RFC5322.From header, leaving only the display part to assert the original author. 

Only in the very narrow situation where you have an EAI mail system
and a non-EAI mail client, and the POP or IMAP server wants to give a
version of an incoming message to the client.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Wed, 9 Nov 2016 12:29:14 -0600 (CST)

----- Original Message -----
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Cc: "dcrocker" <[email-masked]>
> Sent: Sunday, November 6, 2016 2:08:03 PM

> You can ask Barry how much he expects this to affect ASCII mail, since

Yes indeed, this happened after I commented in last call that the then draft if promoted, would create much problems in identifying the author for receivers. I'm glad that much text was added to precise the boundaries of this imperfect solution.

On a similar note.

Calendar invites also seems to have a weird concept of author.

When A sends you an invite to a meeting, and you decide to add B to the list of invitees to the meeting. The invitation to B to the meeting is not coming RFC5322.From you but RFC5322.From A.

---

From: Brandon Long <[email-masked]>
Date: Wed, 9 Nov 2016 14:18:00 -0800

I think the EAI discussion took a turn a bit, but my point was:

EAI sender sends mail to an EAI capable mailing list which has members
which are not EAI capable is a similar scenario to what we're discussing
here for DMARC.

Ie, in order to resend the message, the choices are:
1) Do nothing and maybe the receiver allows the EAI message despite it not
conforming to RFC 5322 and despite the receiving mail server not
advertising SMTPUTF8... or maybe it rejects it.

2) Downgrade the message such that everyone on the list receives something,
even if not what we'd prefer they receive

3) Don't forward EAI messages to non-EAI capable members

4) Don't accept any EAI messages to the mailing list if there are any
non-EAI capable members

Now, it turns out that the majority of mail software is probably fine with
#1 with some level of degradation, so we're less likely to see #2 than we
are in the DMARC case.  Even so, at least this is an ability one could
probe, so we could know when to downgrade and when not to, theoretically...
a mailing list could also interpret DMARC rejects, I guess, and learn when
to downgrade and not on a per-recipient basis.

I would think that both #3 and #4 are less polite choices, and ditto with
applying them to DMARC.

In any case, I'm sure the EAI folks discussed what to do in this scenario,
but I'm not really discussing whether or not #2 is within spec as much as
I'm talking about the better support for your users in an imperfect world
and drawing a parallel to DMARC.

Brandon