Subject: DMARC methods in mailman --- [LEDE-DEV] DMARC related mass bounces / disabled subscriptions (fwd) Jo-Philipp Wich: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Dec 2016 09:25:48 -0500

It is unfortunate that the IETF hasn't shown more leadership here.
Auto-learning address books are going to have a problem with From lines that
say:

        First Last Name Via LISTNAME <[email-masked]>

since this will hijack "First Last" to point to the list, which is going to
cause all manner of email leaks.  Maybe we can do better there.

Subject: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions
From: Jo-Philipp Wich <[email-masked]>
To: LEDE Development List <[email-masked]>
Date: Tue, 13 Dec 2016 21:50:32 +0100
List-Id: <lede-dev.lists.infradead.org>

Hi list,

a recent mailing list post from a DMARC enabled domain caused a large
flood of bounces from various mail providers, causing an automatic
disabling of about 190 subscriptions [1].

I re-enabled those subscriptions manually so there is no need for
further action on your side.

In order to mitigate this problem in the future, I configured this list
to wrap mails from DMARC enabled domains into an outer mail using the
mailing list itself as sender [2].

Please excuse the inconvenience caused by this issue.

Regards,
Jo

1:
http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html
2:
https://wiki.list.org/DOC/Mailman%202.1%20List%20Administrators%20Manual#line-544

_______________________________________________
Lede-dev mailing list
[email-masked]
http://lists.infradead.org/mailman/listinfo/lede-dev

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Dec 2016 16:35:42 +0200

Hi, Michael

So what do you suggest we do?  

I think something like the following will not have the same problem:

        IETF discussion list on behalf of Michael Richardson <[email-masked] <mailto:[email-masked]>>

But that just saves us from data leakage. It doesn’t get the right value into the address book.

Yoav

> On 14 Dec 2016, at 16:25, Michael Richardson <[email-masked]> wrote:
> 
> 
> Date: 13 December 2016 at 22:50:32 GMT+2

---

From: Paul Wouters <[email-masked]>
Date: Wed, 14 Dec 2016 10:29:09 -0500

> On Dec 14, 2016, at 09:35, Yoav Nir <[email-masked]> wrote:
> 
> Hi, Michael
> 
>         IETF discussion list on behalf of Michael Richardson <[email-masked]>

On my mail reader that will show me a list of abbreviated senders who are all "IETF discussion list on behal"

This is already the case for me on the unbound mailing list and makes it basically unreadable for me.

Paul

---

From: Dave Crocker <[email-masked]>
Date: Wed, 14 Dec 2016 10:52:59 -0800

> <[email-masked] <mailto:[email-masked]>>

I'd guess that that would not improve things all that much.  The best I 
can suggest, to get the address book entry into a more reasonable place, 
would be something like

    Mailing list name (on behalf of author) <list-mailbox@list-hostname>

eg,

    IETF Discussion List (Author - Michael Richardson) <[email-masked]>
This at least moves the variable information (author-related) into a 
comment string...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Dec 2016 13:44:28 -0500

> value into the address book.

Agreed.

I think that there are two problems that we haven't solved relating to
address books.

1) a standard header which says, "The stuff in the From: address is useless,
   please don't remember". It might also indicate the whole "this mailbox
   is not monitored" business.

2) a standard header which says, "If you want to remember who this was from,
   you should record XYZ"

Of course, From: was supposed to be (2), and we also have Sender:,
and we have the SMTP From which was supposed to be for errors.

(2) might really be a no-op with no legitimate use, and/or it might have
    some significant downside.

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Dec 2016 13:46:44 -0500

> it basically unreadable for me.

Yes, that's why nobody likes the DMARC "work around" that munges the From:
address.

But, the alternative is that some email that someone autocompletes
to Paul Wouters, auto-learnt from a post to "unbound" or some other list,
goes to the list rather than you.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Dec 2016 15:13:58 -0500 (EST)

> goes to the list rather than you.

False dichotomy.

Paul

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 16 Dec 2016 15:27:04 -0500

The real problem with all of these schemes is as they make life easier
for the user, it also makes life user for the phishers.  So for
example, if we start adding a mail header field "this is *really* the
sender", or there is a standard way to parse it out of the comments of
the from field, then it will also provide a better user experience and
a better user interface to display that as the summary line of the
e-mail, and in the mail headers that are displayed for the user.

And the moment you do that, the phishers will use that to exploit
stupid uesrs, and then there will be a DMARCv2 that will break that
field, and perhaps, break mailing lists again.  :-(

       	   	    	  	  		- Ted

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 16 Dec 2016 20:39:06 +0000

> field, and perhaps, break mailing lists again.  :-(

The real problem that DMARC "solves" is reducing the work-load of
the abuse desks of the domains publishing DMARC records.  DMARC
has nothing to do with protecting end-users from phishing.

When it is more difficult to forge an email from a Yahoo user, it
is more convenient for the phisher to fake an address from some
other domain, and then Yahoo deals with fewer complaints.

The RFC2822.From field is not a particularly important element in
determining whether a phishing email is effective.  What matters
is sufficiently compelling message content.  

There too little correlation between the purported (in message
content) sending organization and the RFC2822.From in a large
fraction of legitimate email, for users to carefully check or rely
on that field.

-- 
	Viktor.

---

From: [email-masked]
Date: Sat, 17 Dec 2016 00:45:44 -0800 (PST)

> fraction of legitimate email, for users to carefully check or rely

And the various fixes, hacks, workarounds, and so on to the problems caused by
DMARC are ony weakening that correlation further.

				Ned

---

From: Randy Bush <[email-masked]>
Date: Sat, 17 Dec 2016 19:52:52 +0900

dmarc is sorely broken and all the amielorations have not good side
effects.  so the question to me is whether we can move the pain closer
to the cause?

randy

---

From: S Moonesamy <[email-masked]>
Date: Sat, 17 Dec 2016 03:15:43 -0800

Hi Michael,
>It is unfortunate that the IETF hasn't shown more leadership here.

Please see https://www.ietf.org/mail-archive/web/ietf/current/msg99781.html

>cause all manner of email leaks.  Maybe we can do better there.

The above format is already being used by at least one non-IETF 
mailing list.  Pointing the author's name to the list address is not 
a good idea.  People looking for a solution will implement what they 
can find in the absence of a standard.  At some point in time that 
solution becomes the real standard even if an ill-timed standard is published.

Regards,
S. Moonesamy

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 17 Dec 2016 07:02:46 -0500

> other domain, and then Yahoo deals with fewer complaints.

I don't think it's difficult at all to forge an email from a Yahoo user.
And it'll even dutifully be marked as valid courtesy of Yahoo itself:

	Yahoo Says 1 Billion User Accounts Were Hacked                          
	http://www.nytimes.com/2016/12/14/technology/yahoo-hack.html    

Please note that this is in addition to the earlier announcement
of 500M hacked accounts.

But hey, at least they got to do this:

	Yahoo breaks every mailing list in the world including the IETF's
	http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html

Yeah.  That was worth it.  Definitely.

---rsk

---

From: Yoav Nir <[email-masked]>
Date: Sat, 17 Dec 2016 15:20:17 +0200

> On 17 Dec 2016, at 12:52, Randy Bush <[email-masked]> wrote:
> 

Hi, Randy.

It’s hard to move the pain in a predictable way. If I send you an email message and it’s not delivered or gets mangled or goes in your spam folder, who feels the pain? That depends on which of us needs the email more. 

The group you want to feel the pain are the administrators who add DMARC records, but other than spamming them with error reports, there’s not much we can do. I don’t think the administrators at Yahoo care too much whether their users are able to use IETF mailing lists or not.

As a proxy we can “punish" those senders who have a DMARC record for their domain. 

If we do nothing, their messages sometimes get lost. They have real problems participating effectively in the IETF unless they switch to using gmail or hotmail accounts like many of us have already done. But that gives us pain as well because we’re missing messages as long as they keep using their own accounts.

If we apply the mitigations only to such accounts, we solve the bounce issue, but then depending on the solutions we poison some of the other participants’ email addresses, or we make the UI show weird unhelpful things. Seems like everybody else gets the pain.

Yoav

---

From: Randy Bush <[email-masked]>
Date: Sat, 17 Dec 2016 22:26:38 +0900

yoav,

> It’s hard to move the pain in a predictable way. If I send you an
> email message and it’s not delivered or gets mangled or goes in your
> spam folder, who feels the pain? That depends on which of us needs the
> email more.

my mail fu is not deep.  but seems to me that we're talking about
mailing lists here, not tina telling me where to pick up €1k.  so
move the pain to the users at yahoo (they're getting used to high
levels of pain) and let them move off yahoo or not play.

randy

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 17 Dec 2016 10:14:51 -0500

On Sat, Dec 17, 2016 at 03:20:17PM +0200, Yoav Nir wrote:
> spam folder, who feels the pain? That depends on which of us needs
> the email more.

The primary problem is that DMARC is fundamentally flawed, and was not
enacted using a standards process that respected all of the
stakeholders.  As a result, it fundamentally becomes a matter of power
politics.

If there are a bunch of people who need to participate in a particular
mailing list --- say, IETF mailing list or the Linux Kernel
development lists --- more than they need to stick with a particular
mail provider, it becomes possible to say to them, "you want to
participate in our community"?  Change mail providers.

In the cases where a mailing list community badly needs the Yahoo
users, Yahoo can dictate to the mailing list --- change your mailing
list software and inflict pain all off your mailing list users, or you
don't get access to our e-mail user community.

> The group you want to feel the pain are the administrators who add
> DMARC records, but other than spamming them with error reports,
> there’s not much we can do. I don’t think the administrators at
> Yahoo care too much whether their users are able to use IETF mailing
> lists or not.
> 
> If we do nothing, their messages sometimes get lost. They have real
> problems participating effectively in the IETF unless they switch to
> using gmail or hotmail accounts like many of us have already
> done. But that gives us pain as well because we’re missing messages
> as long as they keep using their own accounts.

Yeah, it's the "sometimes mail gets lost" problem which is the main
issue.  So it might actually be better to have the mailing list
software refuse to accept a mailing list posting from a domain with a
DMARC record, and it can be bounced back to the sender immediately
with a "sorry, try again using some e-mail address that does not have
DMARC support".

But again, doing this fundamentally is a game of power politics ---
just as DMARC being inflicted on the entire e-mail ecosystem was a
matter of power politics.

Cheers,

					- Ted

> If we apply the mitigations only to such accounts, we solve the
> bounce issue, but then depending on the solutions we poison some of
> the other participants’ email addresses, or we make the UI show
> weird unhelpful things. Seems like everybody else gets the pain.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Dec 2016 10:52:46 -0500

> The group you want to feel the pain are the administrators who add DMARC records, but other than spamming them with error reports, there’s not much we can do. I don’t think the administrators at Ya…

Strictly speaking, what causes these providers pain is their customers leaving.   However, given that Yahoo recently had a billion accounts hacked, I suspect that the IETF’s DMARC settings are not going to provide any comparatively strong motivation for leaving.   And unfortunately one of the big DMARC sites is google.com <http://google.com/>; I really doubt anyone is going to quit their job at Google so they can participate in the IETF, and while we can certainly make it impossible for them to participate without using a different mail provider, the question is, is this the right way to spread the pain?

It’s certainly one of the options we discussed when this came up earlier.

BTW, speaking of obnoxious header munging, it would be a kindness, Randy Bush, if you would stop munging the headers on your replies to the IETF mailing list to say "IETF Disgust."   I find this really offensive, and consequently I have to go in and re-edit the name back to "IETF Discussion List" to undo your vandalism.   If the list so disgusts you, why not unsubscribe?

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Dec 2016 10:56:17 -0500

On Dec 17, 2016, at 6:15 AM, S Moonesamy <[email-masked]> wrote:
>>        First Last Name Via LISTNAME <[email-masked] <mailto:[email-masked]>>
>> 
> The above format is already being used by at least one non-IETF mailing list.

Yes.   And changing it to the mailing list also has problems in terms of readability.   How about:

	For First Last via Listname <[email-masked] <mailto:[email-masked]>>

This is brief, avoids the autocomplete fail, and gets the job done.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 17 Dec 2016 08:39:24 -0800

Hi Ted,
At 07:56 17-12-2016, Ted Lemon wrote:
>For First Last via Listname <[email-masked]>
>

The above adds a string to prevent the auto-complete feature from 
adding an email address which is not the author's email address.  At 
this stage it is worthwhile to consider the idea.

The bounce problem [1] is a case of the IETF violating an IETF "standard".

Regards,
S. Moonesamy

1. https://www.ietf.org/mail-archive/web/ietf/current/msg100100.html

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Dec 2016 14:55:09 -0500

+1.  FWIW, I have to agree with Ted here.    When a large mail
provider knowingly and unrepentantly does something that
violates well-established and well-defined standards and fouls
up mailing lists for others, especially when that provider also,
within their business model, pushes a "forum" service that is an
alternative to those mailing lists, and then effectively says
"everyone else needs to adapt to what we are doing",  we should
not be rushing to make the Internet worse by adapting to those
moves.  If that large provider joins with other large providers
to either develop the technique or push it on others, that is
known in some countries as a conspiracy in restraint of trade,
and, again, not something about which we should be participating
or abetting.  

If the net effect is that users of that provider's systems have
to find another mechanism to participate in IETF work, that is
the fault of the provider, not the IETF.   And, as Randy
indirectly mentioned, if that provider has repeatedly been the
victim of attacks that compromise user information at very large
scale, we may sympathize with them as victims (even through
failure to notify the people whose information was compromised
for months should reduce the sympathy level somewhat) but, if
any action by us is called for, it is reviewing our security
standards and recommendations to see if more or different
measures should be explicitly recommended as best practices.
If the best practices are already clear and that provider is not
following them, it is Not Our Problem except insofar as some of
us, in other capacities, might suggest either that their users
move sensitive information elsewhere or support non-technical
mechanisms for getting the provider's attention.

Just my opinion, of course, but the fact that a provider has a
zillion users doesn't mean that a "running code" doctrine mean
that we need to change standards or internal IETF practices to
conform to what they decided to do any more than the observation
that they have allowed personal data for many of those users to
be compromised makes that ok.

best,
    john

--On Saturday, December 17, 2016 10:14 -0500 Theodore Ts'o
<[email-masked]> wrote:

>> It's hard to move the pain in a predictable way. If I send
>> you an email message and it's not delivered or gets mangled
>> or goes in your spam folder, who feels the pain? That depends
>> on which of us needs the email more.
> 
> The primary problem is that DMARC is fundamentally flawed, and
> was not enacted using a standards process that respected all
> of the stakeholders.  As a result, it fundamentally becomes a
> If there are a bunch of people who need to participate in a
> particular mailing list --- say, IETF mailing list or the
> Linux Kernel development lists --- more than they need to
> stick with a particular mail provider, it becomes possible to
> say to them, "you want to participate in our community"?
> Change mail providers.
> 
> In the cases where a mailing list community badly needs the
> Yahoo users, Yahoo can dictate to the mailing list --- change
> your mailing list software and inflict pain all off your
> mailing list users, or you don't get access to our e-mail user
> community.
> 
>> The group you want to feel the pain are the administrators
>> who add DMARC records, but other than spamming them with
>> error reports, there's not much we can do. I don't think
>> the administrators at Yahoo care too much whether their users
>> are able to use IETF mailing lists or not.
>> 
>> As a proxy we can "punish" those senders who have a DMARC
>> record for their domain. 
>> 
>> If we do nothing, their messages sometimes get lost. They
>> have real problems participating effectively in the IETF
>> unless they switch to using gmail or hotmail accounts like
>> many of us have already done. But that gives us pain as well
>> because we're missing messages as long as they keep using
>> their own accounts.
> 
> Yeah, it's the "sometimes mail gets lost" problem which is the
> main issue.  So it might actually be better to have the
> mailing list software refuse to accept a mailing list posting
> from a domain with a DMARC record, and it can be bounced back
> to the sender immediately with a "sorry, try again using some
> e-mail address that does not have DMARC support".
> 
> But again, doing this fundamentally is a game of power
> politics --- just as DMARC being inflicted on the entire
> e-mail ecosystem was a matter of power politics.
> 
> Cheers,
> 
> 					- Ted
> 
>> If we apply the mitigations only to such accounts, we solve
>> the bounce issue, but then depending on the solutions we
>> poison some of the other participants' email addresses, or
>> we make the UI show weird unhelpful things. Seems like
>> everybody else gets the pain.
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Dec 2016 15:19:45 -0500

> with a "sorry, try again using some e-mail address that does not have

I really think that this is the right answer for our community.
The DMARC policy is not to forward, and we should respect it.

When ARC gets standardized, we should implement it.

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Dec 2016 15:29:34 -0500

--On Saturday, December 17, 2016 08:39 -0800 S Moonesamy
<[email-masked]> wrote:

> The above adds a string to prevent the auto-complete feature
> from adding an email address which is not the author's email
> address.  At this stage it is worthwhile to consider the idea.
> 

Maybe this is what you meant by the scare quotes, but the IETF
has been fairly clear -- in RFC 5321 and 5322 and elsewhere--
that 

(1) Mailing lists can be handled at MTA level, in which case the
backward-pointing envelope address is changed to point to the
list but that, other than adding trace information (including
List identification), the headers and message body should be
unchanged.

(2) Mailing lists can also be handled at MUA level, in which
case "Resent-" fields are added, possibly also with List
information, but the header "From:" and "Sender:" fields are to
be unchanged.  

(3) Because we deliberately do not have standards about what an
MUA can do -- precisely because it is ultimately an agent acting
on behalf of the end user -- such a system can plausibly
construe such a message as being received, modified as desired,
and then forwarded to a list of others.   Again, there is no
standard, but treating mailing list traffic that way opens up a
whole series of potential attacks because, if the "MUA can make
changes" model is applied, nothing prevents such an MUA from,
e.g., changing every instance of "black" in the message body to
"white".

(4) We have never encouraged anything that attributes semantics
to either a name phrase (<display-name> in RFC 5322-speak).
While we have never taken a position about auto-complete and
populating address books based on those fields, doing the latter
is fraught with risks, particularly if all I need to do to
divert mail from Ted to you to an attacker is to send him a
message with a "From:" header field of 
    S Moonesamy <[email-masked]>

See my other message about the principle at work here.

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 Dec 2016 11:14:34 +1300

> I really think that this is the right answer for our community.

I don't. Accept the posting but also send a friendly warning seems to do less damage.

> The DMARC policy is not to forward, and we should respect it.

Why does DMARC, which is a broken solution, deserve that much respect?

> When ARC gets standardized, we should implement it.

Assuming it solves the problem, sure. But if it doesn't, the problem will
get much worse.

    Brian

---

From: "John Levine" <[email-masked]>
Date: 18 Dec 2016 02:28:23 -0000

In article <9AD6AAD6812D3B9F8379226B@PSB> you write:
>alternative to those mailing lists, ...

While I am no fan of what Yahoo has done, I think we should limit the
conspiracy theorizing.  I have it on excellent authority that the
reason Yahoo turned on DMARC was entirely the user complaints about
spam with forged addresses taken from stolen address books.  It had
nothing to do with Yahoo Groups.

Yahoo management knew this would screw up every mailing list in the
world, and they explicitly didn't care.  I'm reasonably sure that the
people who run Yahoo Mail had different opinions but they didn't get
to make the decision.  While it is true that it would not be hard to
circumvent DMARC, crooks are as lazy as the rest of us and I continue
to be surprised at the amount of phish stopped by DMARC's simplistic
checks.

I hear that the amount of legit mail that DMARC breaks is well under
1% of the total non-spam mail at large providers, and even though they
know it is mail that the recipients are very interested in, it's hard
to make a business case for doing something for that 0.5 % unless they
are very sure it won't let a lot of the phish back in.  That's the
rationale for ARC, which is a complicated crock, but lets the
provlders make a reasoanble guess about what's non-spam from mailing
lists.  (FYI, they also tell me that legit lists leak spam all the
time due to compromised or forged subscriber accounts, so it has to be
more than just whitelisting the lists.)

>the fault of the provider, not the IETF.   ...

I appreciate the theory, but we also need to consider how much blood
loss we are willing to accept to cut off our noses to spite our faces.
It is pretty clear that within the next year Gmail will turn on a
DMARC policy, too, and I expect other large mail providers to turn it
on, too.  

If we tell people, sorry, you can't participate in the IETF using the
giant mail providers you use for everything else, what do you expect
the response to be?  Wow, what a bunch of noble principled idealists,
or wow, I don't have time for this nonsense, maybe I'll go work on
some open source stuff on github instead.  We have enough trouble
recruiting people now without putting more roadblocks in their way.

A few of us have been doing some experiments on DMARC avoidance,
looking to see if there's something we can do that will survive DMARC,
not screw up the mail too badly so it's legible and recipients can
reply reasonably, while uglifying it to remind people whose fault it
is.  Some of the possibilities involve wrapping the real message in an
outer one, some involve changing the From: address to a mutated
version of the sender's address (*not* the list's address.)

Maybe ARC will work well enough that we won't have to do anything, but
I expect ARC will be a half solution at best, since it assumes
recipient MTAs have a rather sophisticated filter system that can
handle all the stuff in the ARC chain of forwarding headers.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 18 Dec 2016 02:29:03 -0000

>The DMARC policy is not to forward, and we should respect it.

How many IETF participants are we willing to lose over this
principled position?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 17 Dec 2016 18:38:07 -0800

> Assuming it solves the problem, sure. But if it doesn't, the problem will

Folks,

I am probably more frustrated about the expanded use of DMARC than most 
folk, since I participated in creating the DMARC spec.  For the 
constrained scenario that motivated its design -- let's call it b2c -- 
it works pretty well.  The expanded use -- let's call that c2c -- was 
initially the ad hoc choice of one service provider, but it turns that 
quite a few others also like it: there is a broad-based belief in that 
community that aggressive requirements for author authentication will 
alleviate many abuse problems.  On the average, the downsides of that 
view do not resonate in that community.

At any rate, the expanded use is what's causing the problems.

There are some realities that folk should note, when forming their 
opinions about this problem:

    1. There is nothing 'broken' about DMARC.  There is a problem with a 
particular use of it, but the mechanism, itself, works as designed.

    2. Mailing lists have always been an odd architectural wrinkle. (I 
commend RFC 5598 to anyone interested in the formalities.) An author 
sends a message to the list address.  The message gets /fully/ 
delivered; that is, it goes into the mailbox specified by the mailing 
list address. The mailing list posts a new message.  Whether the mailing 
list retains all, or only almost all, of the original message, and even 
all of the original envelope (except a new envelope addressee list) it 
is a new message:  And this is worth repeating: if the message undergoes 
any changes beyond classic, minimal MTA addition of tracing information, 
the message being sent is a new message.  But the user-level experience 
is of an author sending to a collection of end recipients.  The users 
don't really experience this as a re-posting.  But the reason it's 
important to understand that it is, indeed, a different message than 
what the author posted is that mailing lists can and do do all sorts of 
damage to the original.  The essential challenge in trying to 
accommodate a mechanism, like DMARC, that is designed to work within one 
posting/delivery sequence, when there is more than one, is that we don't 
currently know how to make it fully seamless.

    3. The folk using DMARC are not violating any rules.  Some are 
causing problems for some of their users and some of the folk that their 
users interact with, but that's different than saying they are violating 
a protocol, or the like.

    4. The folk using DMARC for c2c are not seeing a significant problem 
from that use and they do report significant benefit.  Sitting here in 
the IETF, we might not like their assessment, but it's their business, 
not yours or mine.

    5. The IETF has no meaningful leverage over those service providers. 
  Any thoughts about what to do should keep that in mind.

    6. Any thoughts about what to do should pay very close attention to 
who has to take action, how considerable that action is, how long it is 
likely to take for that action to happen, and what their incentives are 
for taking that action.  And remember that all of this has to satisfy 
business concerns, not good-neighbor appeals.

    7. The providers' affected users have no leverage on their 
providers.  None.

    8. It is easy to tell those providers' users that they should go to 
a different provider, but take a look around for choices of consumer 
email providers:  there are precious few choices on the Internet today. 
And for the affected consumers, they need a free, well-run provider who 
operates at scale.

    9. ARC is expected to help this situation, but I suspect it won't be 
as much help as anyone would like.  At the least, it requires adoption 
by both the mailing lists and the receiving MTAs, and that's a lot of 
adoption to require.

d/
-- 

   Dave Crocker

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 17 Dec 2016 23:15:44 -0500

On Sat, Dec 17, 2016 at 06:38:07PM -0800, Dave Crocker wrote:
>    4. The folk using DMARC for c2c are not seeing a significant problem from
> that use and they do report significant benefit.  Sitting here in the IETF,
> we might not like their assessment, but it's their business, not yours or
> mine.

Right, the problem is not with c2c, where the affected mail might be
0.5%.  But for d2d (developers to developers), it's much more serious.

>    5. The IETF has no meaningful leverage over those service providers.  Any
> thoughts about what to do should keep that in mind.

That's been clear.  To the extent that though that some service
providers might want to have developers stay on their platform because
they might be powerful influencers, there might be *some* influence,
but it is admittedly very little.

>    7. The providers' affected users have no leverage on their providers.
> None.

Well, it *might* be that Google might not appreciate headlines of the
form, "Linus Torvalds is leaving gmail because Gmail has become
fundamentally incompatible mailing lists", but it is again,
admittedly, very small.

>    8. It is easy to tell those providers' users that they should go to a
> different provider, but take a look around for choices of consumer email
> providers:  there are precious few choices on the Internet today. And for
> the affected consumers, they need a free, well-run provider who operates at
> scale.

So what we might end up with, in the long run, is mailing lists will
only work with developers who switch to mail services such as, for
example, fastmail.fm.  But there might not be mail services for
consumers that are compatible with mailing lists.  That would be sad,
in that it would involve a partial fork of the Internet mail system,
one for Eloi and one for the Morlocks, using Neal Stephenson's analogy
from "In the Beginning Was the Command Line".

But again, as you have said (and I agree) we have no control over the
big mail providers.  The only thing we have control over is any
mailing list servers we might happen to have administrative control
over, and what kind of pain we want to inflict on our particular
developer community (whether it is standards development or open
source development).

>    9. ARC is expected to help this situation, but I suspect it won't be as
> much help as anyone would like.  At the least, it requires adoption by both
> the mailing lists and the receiving MTAs, and that's a lot of adoption to
> require.

I have the same worry that ARC may not do as much to help as has been
hoped.  Certainly not in the short term.  That's because it won't just
be mailing list servers that will need to adopt ARC, but also mail
forwarding services such as those used by alum.mit.edu,
alumni.stanford.edu, linux.com, etc.

Basically, DMARC is a classic tragedy.  It's playing out in a fairly
inevitable fashion, and there's nothing we can do to change the basis
of the tragedy; only how we react to it.

I suspect the best in the DMARC world where ARC turns out not to be
completely successful is a setting where mailing list recipients can
specify whether their mail service honors DMARC requests, and if it
does, *and* if the sender is one that has a DMARC policy, the From
field will have to get mangled, and if that screws up the recipient's
Yahoo or GMail contacts database, it will be up to that mail provider
to decide how to deal with it.

						- Ted

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Dec 2016 00:21:50 -0500

--On Sunday, December 18, 2016 02:28 +0000 John Levine
<[email-masked]> wrote:

>> up mailing lists for others, especially when that provider
>> also, within their business model, pushes a "forum" service
>> that is an alternative to those mailing lists, ...

> While I am no fan of what Yahoo has done, I think we should
> limit the conspiracy theorizing.

I really didn't claim a conspiracy.  I was just pointing out
that, intentionally or not, they stood to benefit from
disrupting mailing list traffic,  IANAL, but antitrust lawyer
acquaintances tell me that, if a player is sufficiently dominant
that its behavior can cause damage to smaller actors and that
damage works to its advantage, intent may not be a requirement
for violating the law.

>  I have it on excellent
> authority that the reason Yahoo turned on DMARC was entirely
> the user complaints about spam with forged addresses taken
> from stolen address books.  It had nothing to do with Yahoo
> Groups.

I have no doubt that you are correct.  However...

> Yahoo management knew this would screw up every mailing list
> in the world, and they explicitly didn't care.

And that is the point.   It was also the point of mentioning the
potential antitrust situation because I imagine that initiation
of such an action would get the attention of Yahoo management
even if the cries of some small (or even large) number of
zero-revenue mail users would not.

>  I'm reasonably
> sure that the people who run Yahoo Mail had different opinions
> but they didn't get to make the decision.  While it is true
> that it would not be hard to circumvent DMARC, crooks are as
> lazy as the rest of us and I continue to be surprised at the
> amount of phish stopped by DMARC's simplistic checks.

I will defend Yahoo's right to run a mail service that offers
increased protection against some types of attacks, as long as
they accept responsibility for breaking some services and uses
of email, just as I will defend others who choose to violate
Internet standards -- that is why those standards are voluntary.
But the community has the right to quarantine bad behavior
rather than trying to figure out not-quite-as-broken-workarounds
to the damage they cause.   Their users can then decide whether
to live with the restrictions or to move elsewhere.

> I hear that the amount of legit mail that DMARC breaks is well
> under 1% of the total non-spam mail at large providers, and
> even though they know it is mail that the recipients are very
> interested in, it's hard to make a business case for doing
> something for that 0.5 % unless they are very sure it won't
> let a lot of the phish back in.  That's the rationale for ARC,
> which is a complicated crock, but lets the provlders make a
> reasoanble guess about what's non-spam from mailing lists.
> (FYI, they also tell me that legit lists leak spam all the
> time due to compromised or forged subscriber accounts, so it
> has to be more than just whitelisting the lists.)

ok.  And so?   I can remember, and I think you probably can too,
when it was necessary to maintain email accounts on several
different providers because the gateways didn't quite work
(because gateways between disparate systems never completely
work).  That would be a sad result of all of this and the
associated anti-spam/ anti-phishing efforts, but it is outside
the IETF's power to control the situation.  

>> If the net effect is that users of that provider's systems
>> have to find another mechanism to participate in IETF work,
>> that is the fault of the provider, not the IETF.   ...
> 
> I appreciate the theory, but we also need to consider how much
> blood loss we are willing to accept to cut off our noses to
> spite our faces. It is pretty clear that within the next year
> Gmail will turn on a DMARC policy, too, and I expect other
> large mail providers to turn it on, too.  

That reasoning leads to the ability of a handful of large
providers to dictate the way email works in practice.  To
exaggerate only a bit, if that is the situation, the IETF might
as well go out of business, at least at the application layer.
On the other hand, if you are measuring blood loss, some of us
manage a sufficient volume of email that a switch to some of the
remedies that have been proposed would drive us out of the IETF
or at least off of several of the IETF-related lists to which we
now subscribe.  There isn't an option, other than more careful
and carefully-configured use of DMARC (if even that is
sufficient) that avoids shedding any blood at all.  So the
question is not "how much we are willing to accept" but whether
we prefer to shed the blood of those who are violating the
intent of the standards (and I think that intent is a bit more
clear than Dave Crocker's recent note implies) or the blood of
those who are avoiding doing so.

> If we tell people, sorry, you can't participate in the IETF
> using the giant mail providers you use for everything else,
> what do you expect the response to be?  Wow, what a bunch of
> noble principled idealists, or wow, I don't have time for this
> nonsense, maybe I'll go work on some open source stuff on
> github instead.  We have enough trouble recruiting people now
> without putting more roadblocks in their way.

Again, please don't think of it as keeping everyone if we make
kludge-level changes to accommodate Yahoo-style use of DMARC
versus losing people if we don't.  Either option is likely to
lose some people and the questions of how many and how valuable
are probably impossible to assess.  Ted T'so's observations
about developers are particularly relevant in that regard.

> A few of us have been doing some experiments on DMARC
> avoidance, looking to see if there's something we can do that
> will survive DMARC, not screw up the mail too badly so it's
> legible and recipients can reply reasonably, while uglifying
> it to remind people whose fault it is.  Some of the
> possibilities involve wrapping the real message in an outer
> one, some involve changing the From: address to a mutated

I look forward to your report on the results of those
experiments.   As with ARC, I presume alternatives will need to
be deployed to be really useful and effective, but I'd be happy
to be wrong.

> Maybe ARC will work well enough that we won't have to do
> anything, but I expect ARC will be a half solution at best,
> since it assumes recipient MTAs have a rather sophisticated
> filter system that can handle all the stuff in the ARC chain
> of forwarding headers.

I'm trying to adopt a wait and see attitude.

    best,
    john

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 18 Dec 2016 00:58:34 -0500

> recruiting people now without putting more roadblocks in their way.

Um, you're assuming that mailing lists serving open source projects
will either (a) knuckle under to the demands of DMARC, or (b) be
willing to inflict the pain caused by DMARC-workarounds on their
users, aren't you?

I can think of one major open source project (namely, the Linux
kernel) which has refused to do either.

	      	  	     	- Ted

---

From: "John R Levine" <[email-masked]>
Date: 18 Dec 2016 01:04:14 -0500

> willing to inflict the pain caused by DMARC-workarounds on their

Yes, those are the only choices at this point.

> kernel) which has refused to do either.

I'm reasonably sure you're mistaken here.  Don't they rewrite From: 
headers?

R's,
John

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 18 Dec 2016 01:59:05 -0500

On Sun, Dec 18, 2016 at 01:04:14AM -0500, John R Levine wrote:
> I'm reasonably sure you're mistaken here.  Don't they rewrite From: headers?

Nope, vger.kernel.org doesn't rewrite from headers.  An example of a
recent e-mail I received from the linux-fsdevel maliing list:

    Date: Tue, 6 Dec 2016 23:53:57 +0100
    From: David Gstir <[email-masked]>
    To: [email-masked]
    CC: [email-masked], [email-masked], [email-masked],
            [email-masked], [email-masked],
            [email-masked], [email-masked],
            [email-masked], [email-masked],
            [email-masked], [email-masked], [email-masked],
            [email-masked], David Gstir <[email-masked]>
    Subject: [PATCH v2 5/6] fscrypt: Delay bounce page pool allocation until needed
    X-Mailer: git-send-email 2.10.1
		
The fact that the from field is not rewritten is *IMPORTANT* because
rewriting the from field would break the "git am" command[1], since it
uses the From: field to fill in the git commit's from field, and it
would be sad if all of the git commits had an authorship of
[email-masked] or [email-masked].  :-)

[1] https://www.kernel.org/pub/software/scm/git/docs/git-am.html

This is what allows the above mail headers to result in a git commit
which looks like this when applied using "git am":

commit f32d7ac20a5864483c1f96e4970daa083e18bfd1
Author:     David Gstir <[email-masked]>
AuthorDate: Tue Dec 6 23:53:57 2016 +0100
Commit:     Theodore Ts'o <[email-masked]>
CommitDate: Sun Dec 11 16:33:11 2016 -0500

    fscrypt: Delay bounce page pool allocation until needed

----

I will note that at least some people with [email-masked] addresses
have reported *not* having DMARC problems when using mailing lists at
vger.kernel.org, despite the fact that google.com has a dmarc p=REJECT
policy.  I can only guess (from external observation; I haven't looked
at any of the gmail anti-spam algorithms, nor do I have any interest
in looking at them) that even a DMARC p=reject is probably only
resulting in a very high spam score, but using either machine learning
or a manual setting, mail from vger.kernel.org (with perhaps certain
text features from the body of the e-mail very clearly not offering
the sale of pharmaceuticals or making money fast) is given a
sufficiently high score to offset the p=reject score.  And so
apparently mail sent from [email-masked] via a vger.kernel.org mailing
list, is apparently still reaching [email-masked], even though
google.com has a p=reject policy, and even though gmail.com purports
to honor the DMARC spec.

Which brings up something interesting/important about DMARC --- what's
important is not just the DMARC policy of the sender's domain, but
also how the recipient domain is handling the DMARC policy.  It's
pretty clear that some recipient domains are not following the DMARC
specification strictly with respect to rejecting p=reject e-mail addresses.
So while mail sent by a sender who's domain has a p=reject via a
vger.kernel.org mailing list might get accepted by a recipient at
gmail.com, it might not be accepted by a recipient at yahoo.com ---
and that bounce might cause the yahoo.com recipient to get
automatically unsubscribed from the mailing list.

But that's probably fine, because no there are very few developers
using yahoo.com (and probably up to a billion fewer now :-).  And so
as we can see, even honoring DMARC policies can cause mailing list
participants pain; it's not just sending from p=reject domains that
cause pain in terms of possibly unreceived e-mail (and possibly
bumping people in the first category off the list due to
auto-unsubscription policies).

Therefore, a developer-friendly mail service MUST NOT have a p=reject
or p=quarantee DMARC policy, and MUST also ignore DMARC policies on
the receiving end.  Fortunately, these mail services do exist, even if
they aren't the big, free consumer ones.

Cheers,

					- Ted

---

From: "John R Levine" <[email-masked]>
Date: 18 Dec 2016 02:24:03 -0500

> they aren't the big, free consumer ones.

Linux may be enough of a cult that developers will put up with having to 
use a mail account different from the one they use for everything else, 
but as I've said a couple of times already, I don't think the IETF can 
stand the blood loss.

There are some workarounds, maybe ARC, maybe message wrapping, maybe some 
kind of From: munging.  We're looking at them and scratching our heads.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Sun, 18 Dec 2016 02:15:24 -0800

Hi John,
>has been fairly clear -- in RFC 5321 and 5322 and elsewhere--

RFC 7960 states that: "To alleviate unsubscribes to the Mailing List 
due to the messages bouncing because of DMARC, the MLM needs to not 
act on notification messages due to message authentication 
issues".  That would entail interpreting the Enhanced Status Codes, 
specifically the ones related to message authentication failures and 
ignoring them for unsubscription purposes.

>List identification), the headers and message body should be

Yes.  It is the message body change which indirectly causes the 
rejection for mail from those "p=reject" domains.

>information, but the header "From:" and "Sender:" fields are to

Yes.

>e.g., changing every instance of "black" in the message body to

The problem is that we are getting into what a MUA does, e.g. 
auto-completion.  We would also not be following RFC 5322 by making a 
change to the "From:" field [1].  In a way, this validates the 
argument that a whole series of potential attacks is being opened.

>     S Moonesamy <[email-masked]>

Yes.  We might end up having to consider whether to attribute 
semantics to the <display-name> as a way to solve the problem.  Let's 
assume that 20% of IETF mailing list subscribers use a "p=reject" 
domain name in the "From:" field and that they are no longer allowed 
to post messages to the mailing list because of the policy advertised 
by that sending domain.  What should the mailing list moderator do in 
response to complaints from those subscribers?

Regards,
S. Moonesamy

1. This is related to Point 2.

---

From: Rich Kulawiec <[email-masked]>
Date: Sun, 18 Dec 2016 09:04:22 -0500

On Sat, Dec 17, 2016 at 06:38:07PM -0800, Dave Crocker wrote:
> there is a broad-based belief in that community that aggressive
> requirements for author authentication will alleviate many abuse problems.

There was a roughly equivalent belief that requirements for
domain authentication would do the same thing:

	"Spam as a technical problem is solved by SPF."

That belief was wrong.  So is this one.  Even if DMARC (and ARC,
and whatever else comes along) work perfectly, without all the
myriad problems we're currently discussing, the impact on abuse will
be negligible.  For example, since we're talking about Yahoo and its
latest massive security breach: I get spam -- all day, every day --
in my spamtraps from Yahoo, and yes it really is from them.   It flows
nonstop, as it has for many years, because they simply don't care to
make it stop.  So it doesn't matter if it's authenticated as really from
them, and further authenticated as really from a particular user account:
this is accurate but useless information because they won't do anything
with it.

Dealing with abuse doesn't require any of these technologies.  It requires
organizational committment to running a well-staffed, well-qualified
abuse desk that responds to EVERY abuse report promptly, efficiently,
and accurately, and which is empowered to take the actions necessary to
make the abuse stop.  Yahoo is miserably bad at this, and they're not
the only one.

So let's not kid ourselves that these operations are sincerely trying
to do something meaningful about abuse.  They're not.  They've told us
by their actions, for well over a decade, that they simply don't care
about the abuse they emit/support/facilitate.

---rsk

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Dec 2016 09:05:12 -0800

> 0.5%.  But for d2d (developers to developers), it's much more serious.

First, what makes that demographic distinctive?  Are there any other 
distinctive demographic groups that might share the solution space?

Second, it is such a narrow (and small) demographic, any requirements 
specific to it are likely to need solutions specific to it.

> but it is admittedly very little.

The world of consumer-oriented email deals with scale that makes the 
'developer' market segment almost unmeasurably small.  It is unlikely 
any consumer service is going to want, or be able, to make adjustment 
for the developer segment.

> fundamentally incompatible mailing lists", but it is again,

Yahoo's original foray into expanded DMARC use incurred that possible 
expense and, again, the effect was immeasurably small.

> example, fastmail.fm.

Name 3 others that have a significant operational history, very good 
reputation, very low fees, and are likely to be able to handle a 
significantly increased user base.

> alumni.stanford.edu, linux.com, etc.

Yes, forwarding services are another form of message re-posting.  The 
differences from mailing lists are significant, but not with regard to 
DMARC issues.

> to decide how to deal with it.

Expecting end users to take such actions already crosses over into an 
extremely high barrier against adoption.

I believe some mailing lists have adjusted to detection of DMARC (maybe 
just when p=reject?) for a given author by making author From: field 
changes /only/ for such authors.  They don't make changes when mail is 
from non-DMARC authors.

This restricts the scale of the disruptive effect, but doesn't change 
its nature.

d/

-- 

   Dave Crocker

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 18 Dec 2016 13:02:15 -0500

> On Dec 18, 2016, at 12:05 PM, Dave Crocker <[email-masked]> wrote:
> 
> I believe some mailing lists have adjusted to detection of DMARC (maybe just when p=reject?) for a given author by making author From: field changes /only/ for such authors.  They don't make changes when mail is from non-DMARC authors.

The "postfix-users" adjusted to avoid breaking DKIM upstream
signatures, well before DMARC, by avoiding making any changes
to the message body and (most) headers.

At the cost of not adding subject tags or message footers,
the list does not encounter any DMARC issues.  The only
message modification is addition of "List-" headers and
and a "Sender:" header.

Perhaps that's not a viable option for IETF lists. FWIW the
subject tags could be added by upstream authors as a matter
of courtesy.  Indeed [email-masked] has no footers or subject
tags, and would be expected to not fail DMARC after forwarding.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Dec 2016 14:04:01 -0500

--On Sunday, December 18, 2016 09:05 -0800 Dave Crocker
<[email-masked]> wrote:

>...
>> That's been clear.  To the extent that though that some
>> service providers might want to have developers stay on their
>> platform because they might be powerful influencers, there
>> might be *some* influence, but it is admittedly very little.
> 
> The world of consumer-oriented email deals with scale that
> makes the 'developer' market segment almost unmeasurably
> small.  It is unlikely any consumer service is going to want,
> or be able, to make adjustment for the developer segment.

Dave,

While I agree with your analysis, let me suggest a slightly
different formulation (and note this is straying away from the
question, which I understood to be about IETF mailing lists and
DMARC workarounds.  In the fourth quadrant of a conceptual
matrix, there are people whose use of, and dependency on, email
are mission-critical or personally critical and whose daily
email volume is very high.  In the diagonally-opposite first
quadrant are those who may find email very useful but not
actually critical to their lives or work and whose volume is
relatively low.  For simplicity, I'll leave the other two
quadrants as an exercise.

One important thing about that matrix is that the number of
people in the first quadrant is hugely larger than the number of
people in the fourth, to the point that almost any argument
based on number of users, eyeballs, etc., can justify ignoring
the fourth quadrant (and maybe the other two).  In particular,
small inconveniences, or even larger ones for a small fraction
of the already-small number of messages received, are likely to
be accepted in return for a convenient and free email service.
The people in that quadrant typically don't need sophisticated
mail management facilities (except maybe for personal archival
purposes) -- they just don't get enough mail and/or it isn't
important enough.  It might be an exaggeration, but arguments
that everyone should just use Webmail or even proprietary
systems interconnected by gateways that more or less work, are
not far away (such systems can, among other things, easily
develop really effective anti-spam systems if the proprietors
actually find that to be in their business interests.  

The number of Ted's developers or subscribers to IETF lists in
the first quadrant is insignificant, not only because there are
some of them in the other quadrants but because there just
aren't very many of them relative to the total population of
that quadrant.

Now, the questions become one of who is in the fourth quadrant,
how large that quadrant's population is, what features they
need, and how should they get them.  Part of the answer to the
latter is that, while "free" is nice, many of us would happily
pay for better mail management capability and other features
(see recent discussions about IMAP capabilities and
alternatives).  Simply because of mail volume and management
issues, we are probably much more sensitive to standards
conformance, predictability of header field content, etc.  We
might also be less tolerant of systems that simply lose messages
that they consider suspicious than the folks in the first
quadrant (at least if it isn't from someone's easily-whitelisted
grandmother).   If nothing else, a small inconvenience
multiplied by 500 or 1000 or more legitimate messages a day
isn't a small inconvenience any more.   Many of us do pay by
insisting in controlling/ running our own mail servers at
effective costs (including the marginal cost of Internet
connections that allow servers) of hundreds of dollars a month.
As a percentage, I'd guess that the concentration of developers
and active IETF participants in that fourth quadrant is
non-trivial.  

So... do we need different sets of standards (or even best
practices) for the first quadrant and the fourth?   Are we
willing to leave the practices of the suppliers for the first
quadrant users to whatever those large providers decide to do,
such that community consensus-based standards may not even be
relevant?  If we are not willing, do we actually have a
choice... several of the comments in recent days suggests that
the situation is just our new reality and we need to adjust to
it.

My suggestion is that, if we really cannot affect the behavior
of the service providers for the first quadrant, we should
concentrate our efforts on the fourth, making sure that, if
email use and dependency rises in the general population, we
have appropriate working systems and that, in determining IETF
procedures, we should be paying a lot more attention to the
fourth quadrant rather than concentrating on the needs and
preferences of the users in the first quadrant, no matter how
many of them there are.   

I would feel somewhat differently about this if I thought IETF
decisions would have a significant design or decision-making
impact on those large-scale first quadrant providers, but the
evidence, reinforced by the DMARC experience, is that they are
more likely to make decisions that work well for them and their
systems, users, and business models and then leave us to
compensate for any damage as best we can.    Maybe, but just
maybe, we should be thinking more about encapsulating messages
for those cases, as some of us thought would be the MIME remedy
for mail passed through gateways with significant potential for
information loss.

best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Dec 2016 08:20:11 +1300

On 18/12/2016 23:15, S Moonesamy wrote:
...
> response to complaints from those subscribers?

Send them a canned message stating that the only solution available
to them is changing to a different From address that does not have
this issue. What else can they do?

But...

On 19/12/2016 06:05, Dave Crocker wrote:
...
> changes /only/ for such authors.  They don't make changes when mail is 

If ARC fails to solve the problem, I am certain the IETF will have no
choice but to do this (for both p=reject and p=quarantine, I suspect).

    Brian

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Dec 2016 15:21:08 -0500

--On Monday, 19 December, 2016 08:20 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> semantics to the <display-name> as a way to solve the
>> problem.  Let's  assume that 20% of IETF mailing list
>> subscribers use a "p=reject"  domain name in the "From:"
>> field and that they are no longer allowed  to post messages
>> to the mailing list because of the policy advertised  by that
>> sending domain.  What should the mailing list moderator do in 
> Send them a canned message stating that the only solution
> available to them is changing to a different From address that
> does not have this issue. What else can they do?

Note that this is very similar to one of the options for an
SMTPUTF8-capable IMAP or POP server to take when the client does
not present itself as able to accept should messages, i.e.,
"there is a message you could receive (with SMTPUTF8 POP/IMAP)
or send (with a different mail provider) if you were running in
a different environment, but, with your current environment, you
lose."

   john

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 18 Dec 2016 16:13:14 -0500

I’ve found that gmail puts DMARC fails (mostly from Yahoo and Google) into
the spam box, but doesn’t delete it. I check the spam box daily for false
positives, usually caused by DMARC.

Cheers,
Andy

On Sun, Dec 18, 2016 at 2:24 AM, John R Levine <[email-masked]> wrote:

> use a mail account different from the one they use for everything else, but
> as I've said a couple of times already, I don't think the IETF can stand
> the blood loss.
>

---

From: "John Levine" <[email-masked]>
Date: 18 Dec 2016 22:08:28 -0000

>this issue. What else can they do?

Conclude that the IETF has jumped the shark* and go do something else.

As I keep asking, how much blood are we prepared to lose here?

R's,
John

* - American TV reference, see Wikipedia for details

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 18 Dec 2016 17:24:27 -0500

On Sun, Dec 18, 2016 at 02:24:03AM -0500, John R Levine wrote:
> Linux may be enough of a cult that developers will put up with having to use
> a mail account different from the one they use for everything else, but as
> I've said a couple of times already, I don't think the IETF can stand the
> blood loss.

It has nothing to do with Linux being a cult.  It's a matter of
Linux's economic importance.  If you look at who actually writes the
Linux kernel[1], you'll see the vast majority (over 80%) are doing
this work because they are being paid to do it, with over 200
companies contributing work to every Linux kernel release.  These are
all companies that have products using Linux, and if they want to
participate in the development process, then they darn well better
figure out a way to deal with the fact that vger.kernel.org is
unrepentantly *NOT* DMARC-compliant.

[1] https://www.linux.com/publications/linux-kernel-development-how-fast-it-going-who-doing-it-what-they-are-doing-and-who-5

>From looking at the numbers over the past year, the Linux kernel has
been increasing the number of developers contributing in each retreat
during the entire time that we've been giving the middle finger to
DMARC, and it hasn't been a problem.

When I used to be attending the face to face IETF meetings ten years
ago, at that time my impression was that the IETF was that important
and vital as well, and I suspect that if people had been forced to
change mail providers because that was the only way they could get
work done, and the only way they could ship products, they would do
what they would need to do.

I can't speak to the power and respect and importance that the IETF
commands today, but what's important to remember here is that this is,
again, all about power politics.  So when David Crocker tells us that
the mail providers aren't going to back down, regardless of whether or
not it is true, *of course* the the mail providers will try to say
that, because they are trying to intimate people into knuckling under
and accepting DMARC.

Similarly, there is of course a similar game going on with the
vger.kernel.org mail administrators basically telling yahoo.com
subscribers, "sorry, find another mail provider", in that by not
backing down, hopefully that will change the position of the big mail
providers.

It's all basic power negotiating --- the sort of thing that Trump
would understand --- and this is what happens when something like
DMARC is promulgated across the e-mail ecosystem without a standards
process that respects all stakeholders.  The alternative to "rule of
law" or "standards" is "rule of the jungle".

And so at the end of the day, it's all about what your BATNA (best
alternative to a negotiated agreement).  If it really is true that the
IETF is so lacking in power, and is so enervated, that you are afraid
that you will bleed participants if you don't stand firm to DMARC ---
then you will have lost already.  And if it's true, then maybe the
IETF doesn't have the economic power of say, the Linux kernel in
today's computer industry.

I don't think that's true; I certainly hope that it's not true.  But
you're probably in a better position to make that judgement than I.

Cheers,

					- Ted

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Dec 2016 14:33:58 -0800

On 12/18/2016 2:24 PM, Theodore Ts'o wrote:
>    So when David Crocker tells us that

Ted, you are ascribing more concern about this by the providers than I'm 
seeing.

Rather than seeking to invoke some sort of mystical assessment of 
corporate intent, I suggest you do a pragmatic evaluation of actual 
leverage and formulate a practical plan based on it.  Then see who lines 
up in support and follows through with useful action.

> It's all basic power negotiating

Or not.

d/

-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 18 Dec 2016 19:01:29 -0500

> Ted, you are ascribing more concern about this by the providers than I'm 

Having talked to many of the same people at large mail providers that Dave 
has, and also done some policy work for more than one of them* I have to 
agree.  Google has on the order of a billion mail users, and the other 
large providers have hundreds of millions.  The idea that they would weigh 
those users against at most a few thousand people doing Linux or the IETF 
just isn't plausible.

R's,
John

* - expert witness stuff

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 18 Dec 2016 19:54:11 -0500

On Sun, Dec 18, 2016 at 07:01:29PM -0500, John R Levine wrote:
> agree.  Google has on the order of a billion mail users, and the other large
> providers have hundreds of millions.  The idea that they would weigh those
> users against at most a few thousand people doing Linux or the IETF just
> isn't plausible.

And yet, vger.kernel.org is not rewriting its From field, and we have
hard numbers that the number of developers for the Linux Kernel are
not decreasing...

Maybe it's because certain mail providers are not actually honoring
the the DMARC spec by not rejecting mailing list mail from p=reject
domains unconditionally, maybe it's because peoeple have switch mail
domains in order to successfully participate at vger.kernel.org, or
maybe it's a little of both.

Or maybe it's because most companies aren't using DMARC, and any of
the developers are either coming from company addresses, as opposed to
using a lot of big consumer mail providers (which might very well be
the case for the IETF as well).  Speaking of company addresses, one
interesting case study which shows the economic power of Linux was
that it actually caused IBM to except Linux Technology Center members
from having to Lotus Notes (which given the power of IBM Software
Group at the time, was in my opinion a far bigger sign of power than
IBM deciding to invest a billion dollars in Linux).  If you wanted to
interact with the rest of the Linux Community, you weren't going to be
using Lotus Notes.  And guess what; an alternative was provided.  It
had nothing to do with Linux being a cult.  It had to do with a very
simple business decision.

I really do believe the IETF is underestimating how much power it has;
even if it can't move the big consumer mail providers, developers who
want to interact with the IETF will find a way.... and if not, maybe
the IETF doesn't have the power to be an effective standards
organization any more.  (Which certainly seems to be true in the
e-mail space, anyway....)

						- Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Dec 2016 14:16:05 +1300

> Conclude that the IETF has jumped the shark* and go do something else.

The question was what can a mailman list admin do. I don't see another answer,
except setting the 'anonymous list' mode ("Hide the sender of a message, replacing
it with the list address (Removes From, Sender and Reply-To fields").

> As I keep asking, how much blood are we prepared to lose here?

Not that much.

   Brian

---

From: "John R Levine" <[email-masked]>
Date: 18 Dec 2016 20:29:07 -0500

> The question was what can a mailman list admin do. I don't see another answer,

I wrote a shim that goes between Sympa (like Mailman only French) and the 
MTA in an afternoon that does per-user From: line rewriting.  I wrote some 
stuff to do message wrapping in another afternoon.

I don't think I'm a particularly brilliant programmer, and I have no doubt 
that if the IETF found a technical approach we prefer, we could easily 
implement it.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Michael Richardson <[email-masked]>
Date: Sun, 18 Dec 2016 20:59:12 -0500

> recent e-mail I received from the linux-fsdevel maliing list:

Does LKML reject p=reject mail, so that people on providers that respect
p=reject aren't bounced from the mailing list?

---

From: Michael Richardson <[email-masked]>
Date: Sun, 18 Dec 2016 21:19:07 -0500

> Why does DMARC, which is a broken solution, deserve that much respect?

rfc7489 is Informational, via ISE. Not WG or IETF consensus, it's true.
Perhaps the IESG should have blocked it, saying it was a run-around, I don't
know.  Lots of people said it had these problems.

The problem is that it has fundamentally changed how SMTP works (including
SPF and DKIM as part of that "suite"), and it isn't even standards track!

But, if we don't want to process it, then we need to do that in a way that
does not cause people to be kicked off the mailing list.

    > Assuming it solves the problem, sure. But if it doesn't, the problem will

I have no idea if it will work, but at least, if we were respecting DMARC,
then the large providers would have some incentive (if small) to make sure
ARC will work, and will get implemented.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 18 Dec 2016 21:11:21 -0500

> e-mail space, anyway....)

+10.  We are very important, far more important than we often realize.
This is why I have pushed over and over again for us to do something sane.
(If that means you can't participate in NOMCOM if your company can't get
email to work, then that's okay with me.  We also insist they their network
byte order correct.)

If I can't hear from companies with a p=reject policy via ietf.org lists,
then I simply don't care.  I have work to do.  I already delete emails from
people who can't quote sanely.  If it's a mess on my screen, it's probably a
mess in their head too.   Their opinions just aren't taken into account by me.
Sorry: "You must be this tall to ride this ride"

BUT, if their email bouncing kicks me off the list, then I will be very
grumpy.  My spam filtering provider provides me controls to ignore p=reject
when arriving from certain origins, but this doesn't scale well.  I'd rather
the IETF implemented DMARC properly and rejected the email from arriving at
the list.  Or the IETF can repudiate DMARC completely.  To me, it's the
IESG's choice, but this sitting on the fence for four years pissed me off.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 18 Dec 2016 21:28:50 -0500

> How many IETF participants are we willing to lose over this

Define "participants".
I believe that all IESG, IAB, secretariat and WG chairs will grumpily change
mail providers (or stop using their work email) if they have to.  Many have
already had to stop using work email addresses because of other stupidity
they can't control, and we already know that "gmail.com" does not suffer from
this direct problem (at present).

There are probably a few document authors that we might lose.
But, I've lost about five document authors while ROLL WG chair simply due to
attrition (they fell off the planet:  even phoning them did not help), so
I'll bet most WG will not notice, it will be in the noise of other reasons.

So we are down to people reading the list.  Most WGs that make progress have
5, sometimes 10 if they are lucky, actually active people who read, write and
review documents.  If their contribution has been valuable, and they fall off
the list, and the WG chair notices, I'm sure something will happen.

meanwhile, btw, we are having problems actually scheduling enough WG
sessions, so maybe we can affort to "lose" a few.  Maybe, we'll gain a bunch
more who can now actually reliably stay on the list.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Dec 2016 15:52:35 +1300

> that if the IETF found a technical approach we prefer, we could easily 

Yes, but *today* as an IETF list admin I don't have that choice. Objectively
I have exactly two choices: advise the user to change email provider, or rewrite
the From for every single subscriber. I'm not happy with that choice, but unless
somebody in the IETF's IT support does something, that is the choice I have.

    Brian

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 18 Dec 2016 23:52:47 -0500

> On Dec 18, 2016, at 9:52 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> 

A third choice is to configure the list to neither add footers, nor modify
the subject line.  At which point you're no longer breaking DKIM signatures,
and DMARC passes.

-- 
	Viktor.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Dec 2016 09:12:25 +0100

> does not cause people to be kicked off the mailing list.

The ISE mechanism exists to get things published that matter to the
Internet.
It was clear at the time DMARC was published that it would be used
whether it was published as an RFC or not. Publishing the document at
least gave us a stable reference to be angry at.

It would actually be harder to publish a document saying "DMARC is bad,
don't use it, use that other thing instead" if there was no stable
reference for what we mean by DMARC.

I'd describe the so-far inaction more as "shut your eyes and hope it
will go away when others figure out that the solution is bad" than as
"sitting on the fence". Didn't work any better, though.

-- 
Surveillance is pervasive. Go Dark.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 19 Dec 2016 17:16:33 +0200

> On 19 Dec 2016, at 4:11, Michael Richardson <[email-masked]> wrote:
> 
> 

We have power - power over our participants. Not power over any of the major players or even our participants’ employers.

> then I simply don't care.

We don’t hear from companies; we hear from individuals. I care about input from people from Microsoft and Google. I know some working groups where they make up most of the editors. Yes, we can tell them to go get some gmail.com <http://gmail.com/> or live.com <http://live.com/> accounts. That’s adding yet another layer of inconvenience.

>  I have work to do.  I already delete emails from
> people who can't quote sanely.

So Outlook users are out as well?

>  If it's a mess on my screen, it's probably a

Or we could provide a very basic MTA under ietf.org <http://ietf.org/>. Word on the street is that it’s simple enough that even a politician can handle it.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Dec 2016 12:59:35 -0500

Viktor Dukhovni <[email-masked]> wrote:
    >> Yes, but *today* as an IETF list admin I don't have that
    >> choice. Objectively I have exactly two choices: advise the user to
    >> change email provider, or rewrite the From for every single
    >> subscriber. I'm not happy with that choice, but unless somebody in the
    >> IETF's IT support does something, that is the choice I have.

    > A third choice is to configure the list to neither add footers, nor
    > modify the subject line.  At which point you're no longer breaking DKIM
    > signatures, and DMARC passes.

I don't understand how it can "pass".
It's still arriving from an IP address not listed in the SPF, claiming to be
From the provider.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 19 Dec 2016 13:09:29 -0500

> On Dec 19, 2016, at 12:59 PM, Michael Richardson <[email-masked]> wrote:
> 

It passes DKIM, which is sufficient.  SPF checks the envelope, and the list
replaces the envelope sender with the list owner address, so SPF also passes
(for the envelope sender, while DKIM validates the RFC2822.From).

-- 
	Viktor.

---

From: Hector Santos <[email-masked]>
Date: Wed, 21 Dec 2016 05:10:52 -0500

> "sitting on the fence". Didn't work any better, though.

Lets keep in mind the proposed standard ADSP was officially abandoned 
by the same group that pushed the informational status "Super ADSP" 
DMARC replacement protocol.  This replacement did absolutely nothing 
to resolve the long time fundamental problem of addressing "middle 
ware" (list servers) breaking DKIM signed electronics messages nor the 
authorization of 3rd party signers.

We should perhaps recognize it is time to also abandoned DMARC as well 
or fix it with the many suggested improvements, including 3rd party 
authorization DNS lookups which is far simpler and "cheaper" than 
adding additional complexed headers and overhead to the mail system. 
Its not even a "proposed standard" document

We wanted list systems to change but we don't want the change to 
include DNS lookup protocols. Instead, we pushed very complex mail 
altering algorithms and that just isn't working -- obviously.

In my opinion, the IETF has failed the small to mid size 
implementators by catering to the "super large scale" mail providers. 
  That also needs to change within the IETF.  A protocol that is 
written correctly fits all. Size shouldn't matter.   That philosophy 
has been lost, unfortunately.

Happy Holidays

-- 
HLS

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Dec 2016 16:23:32 +0000

Hi Michael,

> IESG's choice, but this sitting on the fence for four years pissed me off.

On a more serious note: IESG is discussing various options as we speak. 
I am the lead on this activity. I would ask people to give IESG a bit of 
time to finish these discussion and don't rehash the DMARC discussion 
all over again.

Best Regards,
Alexey

---

From: Dave Cridland <[email-masked]>
Date: Wed, 21 Dec 2016 17:38:11 +0000

On 21 December 2016 at 16:23, Alexey Melnikov <[email-masked]>
wrote:

> don't rehash the DMARC discussion all over again.
>

Do you even know what this list is *for*?

Dave.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Dec 2016 12:48:48 -0500

> Do you even know what this list is *for*?

Yes.   It’s for seeking consensus during IETF last calls, and discussing general IETF business.

I suspect that wasn’t the answer you were going for, though… :)