Subject: Re: DMARC: perspectives from a listadmin of large open-source lists

From: "John R Levine" <[email-masked]>
Date: 8 Apr 2014 00:21:46 -0400

> differ from the envelope sender. That's why the extra DMARC header
> X-Original-Authentication-Results [1] is needed sadly :-(.

Several people have proposed that, but a few minutes' thought reveals that 
it wouldn't actually help, becuase bad guys can add fake X-O-A-R headers 
just as easily as good guys can add real ones.  You would have to track 
which forwarders are well behaved and add valid X-O-A-R headers, but if 
you can do that, you can skip the header analysis and just whitelist the 
mail from the well behaved forwarders.

Note that there are also well behaved things that don't pass DMARC and 
don't have any original authentication results to report, with the usual 
examples being mail-an-article at the NY Times and Wall Street Journal.

Tracking who is well behaved is quite hard.  You can't ask people to 
self-identify, since again, bad guys will lie.  I was under the impression 
that gmail tried to do it, but given the blizzard of bounces I've seen, 
apparently not.

> The problem described WILL vanish when all mailing list apps implement
> DMARC, but until then, it's really broken.

Mailing list apps can't "implement DMARC" other than by getting rid of 
every feature that makes lists more functional than simple forwarders. 
Given that we haven't done so for any of the previous FUSSPs that didn't 
contemplate mailing lists, because those features are useful to our users, 
it seems unlikely we'll do so now.

If receivers want to implement DMARC policy, they need to make their false 
alarm whitelist first.  This appears to be a substantial, perhaps 
insurmountable, hurdle.

> At the same time, delaying mass usage of the reject policy would limit
> damage.

Reject policy is fine for domains that don't have individual human users, 
or for companies with firm staff policies that all mail goes through the 
company mail server, and employees don't join mailing lists and the like 
using company addresses, or the company provides a separate less strictly 
managed domain for its staff mail. Strict policies will never be 
appropriate for public webmail systems where the users will use their mail 
addresses any way one can use a mail address.  Yahoo appears to understand 
most of this, viz. the different domain for Elizabeth's company mail.

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

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 08 Apr 2014 06:06:27 +0100

On 8 Apr 2014, at 05:21, John R Levine <[email-masked]> wrote:
> Mailing list apps can't "implement DMARC" other than by getting rid of every feature that makes lists more functional than simple forwarders. Given that we haven't done so for any of the previous FUSSPs that didn't contemplate mailing lists, because those features are useful to our users, it seems unlikely we'll do so now.

Well,  Mailman 2.1.16 has the FROM_IS_LIST feature that "Fixes" the problem by putting the list address in the From: field.  That seems to work, except that you lose information (the sender's address) if the list wants to operate a policy of "Reply goes to list".  You can then assure that DKIM signatures are valid and set up SPF, etc.  This also has the effect of letting you operate through the various cloud email platforms that try to validate sender addresses.

But I agree it's broken.

Cheers,
Sabahattin

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 08 Apr 2014 01:18:29 -0400

On Tuesday, April 08, 2014 06:06:27 Sabahattin Gucukoglu wrote:
> > contemplate mailing lists, because those features are useful to our
> > users, it seems unlikely we'll do so now.
> Well,  Mailman 2.1.16 has the FROM_IS_LIST feature that "Fixes" the problem
> by putting the list address in the From: field.  That seems to work, except
> that you lose information (the sender's address) if the list wants to
> operate a policy of "Reply goes to list".  You can then assure that DKIM
> signatures are valid and set up SPF, etc.  This also has the effect of
> letting you operate through the various cloud email platforms that try to
> validate sender addresses.
> 
> But I agree it's broken.

It's unrelated to SPF.  SPF uses Mail From and so on lists that aren't just 
forwarders, the list already uses it's own Mail From.  The only way SPF gets 
roped into this thing is the DMARC use of SPF plus an insistence on "identity 
alignment" to add a requirement that the From domain is in the same domain as 
Mail From.  That's not SPF's fault.

DMARC is interesting for the feedback reports, but I'm certainly not 
publishing reject policies on any domains I have that have real users.

Scott K

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Apr 2014 17:19:18 +1200

Hi,

> On 8 Apr 2014, at 05:21, John R Levine <[email-masked]> wrote:
...
> Well,  Mailman 2.1.16 has the FROM_IS_LIST feature that "Fixes" the problem by putting the list address in the From: field.  That seems to work, except that you lose information (the sender's address)

I would find that quite unacceptable. We need to know who said what
in an IETF discussion, and having to poke around in the headers to find
the original sender would be very painful. It would make some
archive searches impossible, too.

Data: I just had a quick look at my mail archives going back N years. I find
119 messages with 'yahoo' in the From field out of 52367 with 'ietf' in To or CC.

    Brian

---

From: "John R Levine" <[email-masked]>
Date: 8 Apr 2014 02:28:15 -0400

> I think the original scenario you described could be implemented by bad
> players as follows:
> - set up a mailman instance with DMARC support, that forges the XOAR header.
> - Ensure that the mailman outgoing mail passes SPF+DKIM for the domain in question.

Right, except it doesn't even have to be mailman, just spamware that 
creates headers that look like mailman's.  Like I said, if you trust the 
sender to be a real list, deliver its mail.  If you don't, don't.  I don't 
think there are any major conceptual challenges here.

> Those uses shouldn't be considered valid, and NYTimes has already moved
> away from that, at least as of my test 5 minutes ago.

Well, the WSJ does.  This is a perfectly reasonable way to send mail, 
endorsed by decades of practice.

|Date: Tue, 8 Apr 2014 02:24:13
|From: "[email-masked]" <[email-masked]>
|To: [email-masked]
|Subject: WSJ.com - Ukrainian leaders, U.S. slam Russia over new unrest;

The envelope bounce address is <[email-masked]>, again perfectly 
reasonable.

> By implement DMARC, I meant implement XOAR headers; VERP is too useful

As described above, XOAR is not useful because you can't trust it.

Regards,

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 08 Apr 2014 08:13:05 +0100

On 8 Apr 2014, at 06:16, Robin H. Johnson <[email-masked]> wrote:
> And don't start on suggesting Reply-To instead, RFC 2822 already
> noted that it should be set by the author, not the list software [1].

Not that I disagree, but be sure to read the note in RFC 5598 s5.3.

Cheers,
Sabahattin

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Apr 2014 07:48:03 -0500

> Not that I disagree, but be sure to read the note in RFC 5598 s5.3.

Section 5.3 has no "note". I assume you mean the portion on mailing lists:

      5.3. Mailing Lists
      ...
       RFC5322.Reply-To:  Set by - Mediator or original Author

          Although problematic, it is common for a Mailing List to assign
          its own addresses to the Reply-To: header field of messages
          that it posts.  This assignment is intended to ensure that
          replies go to all list members, rather than to only the
          original Author.  As a User Actor, a Mailing List is the Author
          of the new message and can legitimately set the Reply-To:
          value.  As a Mediator attempting to represent the message on
          behalf of its original Author, creating or modifying a
          Reply-To: field can be viewed as violating that Author's
          intent.  When the Reply-To is modified in this way, a reply
          that is meant only for the original Author will instead go to
          the entire list.  When the Mailing List does not set the field,
          a reply meant for the entire list can instead go only to the
          original Author.  At best, either choice is a matter of group
          culture for the particular list.

To the extent anyone wants to claim that this is in conflict with RFC 
5322, it's helpful to remember that a mailing list is a 'mediator' and 
not an MTA.

So it took delivery of a message and is posting a /new/ one.  In formal 
terms, the "author" of the new message is the mailing list; hence it 
gets to set Reply-To...

Consequently, the ending clause in "it should be set by the author, not 
the list software" is not correct.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Robin H. Johnson" <[email-masked]>
Date: Tue, 8 Apr 2014 03:35:32 +0000

Hi,

I'm the listadmin (amongst other things) for Gentoo Linux. Our lists
handle somewhere north of 100k deliveries/day; it's a large deployment
of mlmmj.

I also happen to personally host the lists for my local hackerspace, and
that's where I first noticed DMARC causing problems, because one of our
members activated reject mode on his personal domain, and then all
yahoo+gmail recipients started having bounced mail whenever mail from
the DMARC-progressive user was sent.

I wrote up my findings here:
http://robbat2.livejournal.com/241253.html

If the listserv's outgoing MTA does implement DKIM signing, this problem
will still occur because it's legitimately valid for the From header to
differ from the envelope sender. That's why the extra DMARC header
X-Original-Authentication-Results [1] is needed sadly :-(.

It's really bad because not a single list implementation supports DMARC
yet; mailman is the closest, but still not yet there.

If possible, if everybody could highlight the lack of open-source
support for DMARC in list apps, that would be hugely beneficial to the
cause.

[1] https://sites.google.com/site/oauthgoog/mlistsdkim

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : [email-masked]
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

---

From: "Robin H. Johnson" <[email-masked]>
Date: Tue, 8 Apr 2014 05:16:18 +0000

On Tue, Apr 08, 2014 at 06:06:27AM +0100, Sabahattin Gucukoglu wrote:
> > Mailing list apps can't "implement DMARC" other than by getting rid
> > of every feature that makes lists more functional than simple
> > forwarders. Given that we haven't done so for any of the previous
> > FUSSPs that didn't contemplate mailing lists, because those features
> > are useful to our users, it seems unlikely we'll do so now.
> Well,  Mailman 2.1.16 has the FROM_IS_LIST feature that "Fixes" the
> problem by putting the list address in the From: field.  That seems to
> work, except that you lose information (the sender's address) if the
> list wants to operate a policy of "Reply goes to list".  You can then
> assure that DKIM signatures are valid and set up SPF, etc.  This also
> has the effect of letting you operate through the various cloud email
> platforms that try to validate sender addresses.
This breaks the ability to reply directly to the sender when the
response should NOT be on the list, as well as the ability to put a
sender in a personal killfile.

[1] http://marc.merlins.org/netrants/listreplyto.html List Reply-To
considered harmful.

---

From: "Robin H. Johnson" <[email-masked]>
Date: Tue, 8 Apr 2014 05:37:52 +0000

On Tue, Apr 08, 2014 at 12:21:46AM -0400, John R Levine wrote:
> You would have to track which forwarders are well behaved and add
> valid X-O-A-R headers, but if you can do that, you can skip the header
> analysis and just whitelist the mail from the well behaved forwarders.

The XOAR proposal does specify:
| The X-Original-Authentication-Results header is only useful if the
| forwarder is trusted.  The forwarder is free to modify the headers and
| body of the message however it wishes and can generate new signatures
| over arbitrary X-Original-Authentication-Results headers.  Thus, the
| user SHOULD only trust X-Original-Authentication-Results if the message
| was delivered by known good forwarders, and forwarders SHOULD NOT
| propagate X-Original-Authentication-Results unless the previous
| forwarder is known to be good.
|
| For the purposes of this memo, a message was delivered through trusted
| forwarder if:
| - The DKIM signature passes
| - The DKIM domain is a trusted forwarder

I think the original scenario you described could be implemented by bad
players as follows:
- set up a mailman instance with DMARC support, that forges the XOAR
  header.
- Ensure that the mailman outgoing mail passes SPF+DKIM for the domain
  in question.

Those uses shouldn't be considered valid, and NYTimes has already moved
away from that, at least as of my test 5 minutes ago.
| MAIL FROM:<[email-masked]>
| RCPT TO:<[email-masked]>
| DATA
| ...
| From: robbat2 <[email-masked]>
| Sender: [email-masked]
| To: [email-masked]
| ...

By implement DMARC, I meant implement XOAR headers; VERP is too useful
to running lists to get rid of. Non-VERP bounce messages are still too
generic, even in this modern day.

---

From: [email-masked]
Date: Tue, 08 Apr 2014 09:52:40 -0700 (PDT)

> it seems unlikely we'll do so now.

Actually, mailing lists *can* implement DMARC, just not that way: Do a DMARC
check on all incoming messages, and if the domain policy is one that is
incompatible with the list's own policies - whatever they are - either change
the list's policies to conform to that message or reject it outright,
preferably with a nasty "find another a better mail provider" sort of message.

If the IETF wants to take a leadership position in regards to this issue,
perhaps someone could set this up.

> most of this, viz. the different domain for Elizabeth's company mail.

Which is why support for such policies is even in the specification. The
problem is there's no way to stop inappropriate use of such politicies in
advance of it happening. The best you can do is apply the clue-by-four later.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Apr 2014 10:19:57 -0700

Hi Ned,
>preferably with a nasty "find another a better mail provider" sort of message.

There is some Mailman code which does the above.

>perhaps someone could set this up.

I did a search before asking this question; I did not find any 
answer.  Does anyone know whether the IETF adheres to BCP 167?

Regards,
S. Moonesamy

---

From: "John R Levine" <[email-masked]>
Date: 8 Apr 2014 13:34:35 -0400

> I did a search before asking this question; I did not find any answer.  Does 
> anyone know whether the IETF adheres to BCP 167?

I've never been a big fan of RFC 6377, but this bit seems relevant since 
strict ADSP policies had pretty much the same problems as strict DMARC 
policies.

    For domains that do publish strict ADSP policies, the originating
    site SHOULD use a separate message stream (see Section 2.5), such as
    a signing and Author subdomain, for the "personal" mail -- a
    subdomain that is different from domain(s) used for other mail
    streams.  This allows each to develop an independent reputation, and
    more stringent policies (including ADSP) can be applied to the mail
    stream(s) that do not go through mailing lists or perhaps do not get
    signed at all.

As far as I know, the "participating MLM" thing has never been 
implemented, which makes the C in BCP rather suspect.  My own MLM signs 
the outgoing mail and adds an Authentication-Results: header, but largely 
by default because it's embedded in a mail system that does those things.

Just today I did modify it so that any list mail with a From: address 
@yahoo.com is re written to @yahoo.com.INVALID.  That's the least 
intrusive way I've been able to come up with to mitigate the damage. 
It's also similar to what RFC 6858 suggests for delivering EAI mail to 
systems that can't handle EAI, which is a vaguely similar problem.

Regards,

---

From: Alex Ojeda <[email-masked]>
Date: Tue, 8 Apr 2014 17:58:57 +0000

For mailman and DKIM problems (remote reject) 
Example:
2014-04-06 08:09:43 1WWkxK-0007jZ-T5 H=mail.ietf.org [4.31.198.44]:45557 rejected DKIM : DKIM: encountered the following problem validating gmail.com: signature_incorrect

Fix:
In:
mm_cfg.py
Add:
REMOVE_DKIM_HEADERS = Yes

Alex Matias Ojeda Mercado
NOG CHILE
[email-masked]
+56971922362

-----Mensaje original-----
De: ietf [mailto:[email-masked]] En nombre de [email-masked]
Enviado el: martes, 08 de abril de 2014 12:53
Para: John R Levine
CC: IETF general list; Robin H. Johnson; [email-masked]
Asunto: Re: DMARC: perspectives from a listadmin of large open-source lists

> > The problem described WILL vanish when all mailing list apps 
> > implement DMARC, but until then, it's really broken.

> Given that we haven't done so for any of the previous FUSSPs that 
> didn't contemplate mailing lists, because those features are useful to 
> our users, it seems unlikely we'll do so now.

Actually, mailing lists *can* implement DMARC, just not that way: Do a DMARC check on all incoming messages, and if the domain policy is one that is incompatible with the list's own policies - whatever they are - either change the list's policies to conform to that message or reject it outright, preferably with a nasty "find another a better mail provider" sort of message.

If the IETF wants to take a leadership position in regards to this issue, perhaps someone could set this up.

> If receivers want to implement DMARC policy, they need to make their 
> false alarm whitelist first.  This appears to be a substantial, 
> perhaps insurmountable, hurdle.

> > At the same time, delaying mass usage of the reject policy would 
> > limit damage.

> Reject policy is fine for domains that don't have individual human 
> users, or for companies with firm staff policies that all mail goes 
> through the company mail server, and employees don't join mailing 
> lists and the like using company addresses, or the company provides a 
> separate less strictly managed domain for its staff mail. Strict 
> policies will never be appropriate for public webmail systems where 
> the users will use their mail addresses any way one can use a mail 
> address.  Yahoo appears to understand most of this, viz. the different domain for Elizabeth's company mail.

Which is why support for such policies is even in the specification. The problem is there's no way to stop inappropriate use of such politicies in advance of it happening. The best you can do is apply the clue-by-four later.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Tue, 08 Apr 2014 14:29:48 -0400

By far, the list REPLY-TO feature benefited the layman list user 
inability to figure it out how to reply back to the list by 
manipulating header input fields with the lack of MUA support for a 
3rd reply button:

    REPLY
    REPLY TO ALL
    REPLY TO LIST  <--- NEW

With greater support for LIST-* headers, the MUA can now add the 3rd 
button and the default, natural "reply" action to reply back to the list.

Without it, most layman and even "lazy" veterans can mistakenly and 
naturally click that "reply" button only to unintentionally go 
directly and not to the groupware discussion area A.K.A "mailing list."

You have to look at it from the perspective of the UI ERGONOMICS and 
the support process why it even existed.

That said, it is not natural to TAMPER with mail, especially of the 
body text, but including headers that were not created by the middle 
ware.  However, there has been a historical school of though that 
mailing list server/agent was acting as a NEW MAIL AUTHOR.  I didn't 
think it was 100% kolsher, but it was a rationale for the technical 
justification to tamper with mail; list software is really a "new 
author" therefore it has "right" to tamper with mail.

I didn't generally agree with this, but even our own (commercial) 
Mailing List Server does manipulate the headers in principle to 
improve communications, and of recent as an option to improve DKIM 
resigning logical "faults."

Improving the communications included:

   - Prepare the BOUNCE, ERROR address.  Different remote
     Bouncing software behave differently in how or where
     they get the bounce or error address.  So this one reason
     you will have redundancy, changes in error addresses;
     Sender:, Errors-To: to target all forms.

   - Minimizing mistakes, making it easy for the USER to
     have a "natural" reply back to the list by adjusting
     the Reply-To header.  By far, the preferred intention is
     to reply back to the list.  Newer MUA with list-* header
     and "REPLY TO LIST"  reduces the new to set or strip &
     replace the reply-to field.

There was also major concerns with DKIM tampering with originality. 
It will be an injustice to try to cover, go over all that again here.

Finally, this whole discussion about DMARC is all deja-vu and surreal 
too that the OP is concern now when DKIM with SSP or ADSP had the same 
problems and DMARC does not resolve it.  He knows that. So I see this 
as a marketing effort to push something that clearly will not work for 
the same reasons ADSP did not. Its no different.

In principle, we will always have the same problems with LIST software 
because of the mindset and rationale that the middle ware is a "new 
author" and therefore does not have to respect any SECURITY POLICY 
controls by the originating, authoring, copyright holding domain.  It 
was a clear case of intentional ignorance (don't recognize ADSP, make 
it historic) and tampering of a email security control.

It was the reason the powerful concept of SSP/ADSP did not get the 
wider MARKETING endorsement it deserved.   The main hurdle was with 
LIST systems.

The same problem will be with DMARC.  There is nothing that DMARC can 
do to change that except perhaps advocate (and document) stronger 
middle ware controls to properly follow these security controls.

But you can't have this when DKIM was revised to be based on a 
futuristic, never materializing 3rd party signer control system that 
is consistent and persistent from point to point, end to end, pretty 
much like the SSL/BROWSER market with each browser supporting the same 
3rd party signature framework.  We can not repeat this in the mail 
system -- too  many vendors to begin with. With browsers, there were 
only a few you had to deal with.

We knew all this list problem in DKIM 101. It was part of the original 
charter that any idea to make it work would be secondary to the 
primary purpose of gaining stronger direct domain security controls. 
DKIM and ASDP were part of the original standard track charter.  It 
made perfect engineering sense.

But that seem to change by the "big" list operators who felt that DKIM 
needs be a 3rd PARTY signer control framework with less recognition to 
the original author. SSP which has 3rd party controls was reduced to 
ADSP that allowed for a secured 1st party control.  But that still 
would not work with LIST system unless these middle ware routers 
supports the 1st party controls too.

It was too easy to see that it won't work.  Not thru LIST systems 
without 100% advocated support for honoring these new domain security 
protocol policies.  Instead, it is documented in DKIM related RFCs 
that its OK to tamper with mail as long it was resigned with "trusted" 
3rd party signing domains.  The theory is that if the receivers also 
had a table of the same 3rd party Trusted signers, then it would 
resolve the broken chain of trusted mail problem.

We can't have it both ways.

---
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 08 Apr 2014 15:21:00 -0400

Really?

You knew that our software was the first to suggest and document in 
the 2006 DSAP I-D on how to a MLS will need to handle restrictive 
domain security policies.  RFC 6377 (BCP 167) notes on this came from 
my I-D and the DKIM WG discussions about it whether directly or not.

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

   3.3.  Mailing List Servers

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

    Subscription Controls

       MLS subscription processes should perform a DSAP check to
       determine if a subscribing email domain DSAP 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 DKIM 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.

Our MLS was the first supports this.

During development of RFC6377, the potential interop issues was well 
known. I was able to show this when the middle ware ignores DKIM 
signature controls.

DMARC will not resolve the problem, but .....

Part of the problem has been with the DKIM mindset to make it a 3rd 
party signature framework where the LIST or 'central' mail distributor 
has full control of signatures.  Remember, in the original DKIM, 
making it work with LIST system was a secondary chartered concern. 
That charter changed (or did it?) and not for the better with a lesser 
focus on the author domain policies, and eventually dismantling of 
ADSP, but replaced with DMARC.

Restrictive 1st party controls are by design not to work in the 3rd 
party environment. That was the purpose and intent of the original SSP 
policies, and the reduced ADSP proposal.  DSAP attempted to bring back 
that idea. You could only implement it as described above or by simply 
following the policy in some fashion to not cause downlink issues. 
Intentionally ignoring it was not an option if you wanted to support DKIM.

But DKIM and its deployment documents are in conflict.  It says follow 
ADSP, but it allows for the 3rd party DKIM signing system to ignore it.

Can't have it both ways.

---
HLS

---

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Apr 2014 11:55:58 -0700

Hi John,
At 10:34 08-04-2014, John R Levine wrote:
>I've never been a big fan of RFC 6377, but this bit seems relevant 
>since strict ADSP policies had pretty much the same problems as 
>strict DMARC policies.

Strict ADSP policies do cause problems.

>implemented, which makes the C in BCP rather suspect.  My own MLM 
>signs the outgoing mail and adds an Authentication-Results: header, 
>but largely by default because it's embedded in a mail system that 
>does those things.

There was a message stating that the IETF implemented support for 
DKIM ( 
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09173.html 
).  Given that there is an existing BCP about DKIM and mailing lists 
it might be assumed that the IETF is following it.  There is a 
recommendation in the BCP to reject some types of messages.

My mailing list implementation does not break DKIM signatures.  I 
would not describe it as a "participating MLM" as the postmaster does 
not follow some of the recommendations in that BCP. :-)

>Just today I did modify it so that any list mail with a From: 
>address @yahoo.com is re written to @yahoo.com.INVALID.  That's the 
>least intrusive way I've been able to come up with to mitigate the 
>damage. It's also similar to what RFC 6858 suggests for delivering 
>EAI mail to systems that can't handle EAI, which is a vaguely similar problem.

I found some other domains which implemented DMARC as described at 
http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html  I 
suggest taking that into account if you haven't already done it.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Apr 2014 13:09:11 -0700

Hi Hector,
At 12:21 08-04-2014, Hector Santos wrote:
>domain security policies.  RFC 6377 (BCP 167) notes on this came 
>from my I-D and the DKIM WG discussions about it whether directly or not.

The question I asked was whether the IETF adheres to BCP 167.  I must 
have been aware that your software implemented that draft if it was 
mentioned during the DKIM WG discussions.  I forgot about that as it 
has been a while.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 11 Apr 2014 12:40:24 +0200

> intrusive way I've been able to come up with to mitigate the damage.

Fair enough.  I've copied that suggestion to
http://en.wikipedia.org/wiki/DMARC#Human_policy
Please feel free to amend that page at your leisure.

Ale

---

From: Hector Santos <[email-masked]>
Date: Fri, 11 Apr 2014 17:24:22 -0400

Wouldn't that be tampering with a domain and telecommunications that 
would be valid for all other purposes other than for DMARC?

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sun, 13 Apr 2014 13:37:35 -0400

On 4/11/2014 6:40 AM, Alessandro Vesely wrote:> On Tue 08/Apr/2014 
> Please feel free to amend that page at your leisure.

Hi Alessandro,

You added (I presume):

    According to John Levine, a well known mail expert, the least
    intrusive way to mitigate the damage would be to rewrite the
    From: address in a predictable, comprehensible manner, such as
    the following:

It may be the "quickest" way, but I would consider this the most 
intrusive and even email damaging, extremely harmful suggestion to 
electronic mail communications.

It opens a can of worms, Pandora's box, so to speak, to begin 
suggesting one can modifying and tampering with one the key x822/5322 
mail headers, From:, for any local reason.

In my ethical engineering book, it would just be major TABOO to do 
this. The 5322.From one is the anchor for fundamental electronic mail 
I/O for both networking and non-networking and for other technologies. 
To tamper with it,  it is bound to break other things.

Keep in mind, ADSP also proposed a "radical" DISCARD concept for mail. 
  But because of the ADSP standard track work and synergism at the 
time, we did get RFC2821BIS (RFC5322) to recognize the new reality 
that there are new reasons to ACCEPT and DISCARD rather than ACCEPT 
and BOUNCE without referring to the ADSP work (it was still a draft).

     side note:

     There was also a new modern reality where the SMTP DATA state point
     would be used more as a CALL OUT, SHIM, HOOK to handle new RFC5322
     based Payload technology such as DKIM verification where a ADSP
     policy check would also apply.  One main goal was dynamic processing
     with instant non-bounce notifications.  But with ADSP, there was
     suggestions for an implementation to set a ADSP fail that allows
     the acceptance of mail so it can be quietly discarded. IOW, no
     dynamic 55x rejection at the SMTP level for ADSP fail policies 
because
     that caused problems for the blind mailing list servers.

Yes, it is all complex, but here, the real solution is for John Levine 
and other large list operators to update their mail listing software 
to follow the suggestions in RFC6377:

    RFC6377 DomainKeys Identified Mail (DKIM) and Mailing List

Its not a new problem, its been known since 2006. There are secondary 
DKIM security "wrapper" layers that augment DKIM.  DMARC may be the 
focus, but the issue existed since SSP and ADSP.  If the list service 
is going to resign mail with DKIM, it needs to recognize that DKIM 
does comes with signature security baggage that the not covered by the 
trust model.

So this is a "integration" issue.  Honestly, the changes are not too 
difficult and IMO, it is far less intrusive than changing the 
5322.From.

1) When a new subscriber applies to a list, check for restrictive 
domain policies. Deny subscribers and explain why in the notification 
message.

2) Check for restrictive domains in list mail submissions.

The first one is the piece a cake.  The 2nd one can be more complex 
due to the wider number of software things to do here.

2a) Dynamic SMTP check, reject (55x) the message with policy reason.

2b) Accept message and send a "no access" notification message. 
Explain why.

2c) During the redesign software change, write a one time membership 
scanner to remove restrictive domain members. Send email notification 
explaining why.

Etc.  My main point is that we been doing this for 9+ years.  We knew 
the problems and we have the ideas for solutions.  Whether it was all 
practical and could scale, well, everyone had different opinions here.

But we got a different issue here when list operations don't want to 
change to add policy protocol support but change enough to support a 
pure DKIM-BASE but nothing else.  I fail to see how it can work that way.

This is a "integration" issue and can only be solved using an 
integrated DKIM+POLICY framework and mentality.

-- 
HLS

---

From: Doug Barton <[email-masked]>
Date: Sun, 13 Apr 2014 13:28:50 -0700

> Well,  Mailman 2.1.16 has the FROM_IS_LIST feature that "Fixes" the problem by putting the list address in the From: field.  That seems to work, except that you lose information (the sender's addre…

I haven't seen this suggestion anywhere yet, although I don't follow 
DMARC development, but here goes ...

Building on the FROM_IS_LIST idea, rather than having the From be 
rewritten to simply "[email-masked]" why not establish a convention 
(dare I say "standard?") to encode the real from address and list to the 
left of the @ sign? The rub with DMARC/SPF/DKIM is the domain itself, 
not the whole address.

Something like [email-masked] would 
work. I'm sure others could come up with better suggestions. In this way 
the identity of the sender is preserved, and the sending domain of the 
message satisfies the anti-spam tools. MUAs could then be adapted to 
decode the addresses in this form and show a "real" fake From field.

Given that tools like DMARC more or less work for everything but mailing 
lists (I'm being generous here in the interests of re-framing the 
discussion into solutions instead of griping), and given that mailing 
lists constitute a tiny percentage of overall e-mail traffic, I think 
that the solutions to this problem are going to lie with the mailing 
list software vendors. I think the above would work, but I'm not an 
expert in this area so feel free to tell me why I'm wrong.

Doug

---

From: "John Levine" <[email-masked]>
Date: 13 Apr 2014 21:10:24 -0000

>left of the @ sign? The rub with DMARC/SPF/DKIM is the domain itself, 

This is a minor tweak of the "authenticated phish via on-behalf-of" proposal.

Spammers can send mail that looks a lot like mailing lists, you know.

 From: Paypal Security <[email-masked]>

But wait, I have an even better idea, Nobody ever thought of this one!

 From: Paypal Security <[email-masked]>

R's,
John

PS: You can safely assume that any possible workaround for mailing
list From: lines has been invented, argued about, and discarded at
least a dozen times already.  The response to pretty much all of them
is that you have to know it's a real mailing list to trust the hack,
but if you know it's a real mailing list, just deliver the fripping
mail.

---

From: Doug Barton <[email-masked]>
Date: Sun, 13 Apr 2014 18:59:20 -0700

> This is a minor tweak of the "authenticated phish via on-behalf-of" proposal.

It's not, actually. The defects in XOAR are obvious even to me.

> Spammers can send mail that looks a lot like mailing lists, you know.

What does that have to do with anything? If the message authenticates 
via DMARC/SPF/DKIM then that's a point in its favor in terms of it not 
being spam. If the message comes through with a From: that "looks like a 
mailing list" who cares? Even if that message passes all of the other 
spam filtering mechanisms between it and the user, the user is likely to 
know if they are signed up for a mailing list that the spam message is 
trying to fake, even if it isn't obvious on its face that it's spam to 
start with.

>   From: Paypal Security <[email-masked]>

DMARC/SPF/DKIM will actually benefit that message if it has a valid 
signature. Nothing "mailing list" related about it.

>   From: Paypal Security <[email-masked]>

Same here. And again, if the message comes through with a valid 
signature it's less likely to get caught as spam.

Meanwhile, I'm still not proposing that we train users, or even 
anti-spam software to "recognize" or "validate" mailing list addresses. 
What I'm proposing is a way to send mail from a list with From: 
@domain-of-list.tld so that it can pass DMARC/SPF/DKIM, and allow the 
left side of the @ sign to identify the actual sender of the message.

Doug

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2014 02:49:56 -0000

>left side of the @ sign to identify the actual sender of the message.

Yes, that's the 1980s percent hack.  Do you really think it's a good
idea to reinvent it to get around the defects of the FUSSP du jour?

I agree that it's not plausible to train people to recognize mailing
list addresses.  But what you're proposing is to train people to be
phished, by telling them that a rewritten address from something that
looks sort of like a mailing list is equivalent to whatever the
original address was.  Given that DMARC is supposed to be an
anti-phishing tool, this completely defeats the point.

R's,
John

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 13 Apr 2014 22:57:27 -0400

> anti-phishing tool, this completely defeats the point.

It strikes me that the real way to address some of these issues is to 
add a few new headers to SMTP - to get rid of the overloading of the 
From: and Reply-to: headers associated with mailing lists.  An SMTP 
extension that would absorb some of the well-known and well-understood 
functions of list software.

I have to think a bit about what the full list of headers might be, but 
I'd start with:
From: <original author>
List-From: <mailing list>
Reply-To-Original:
Reply-To-List: <set by list manager>
List-Name:
DKIM signature stuff applied to original message
DKIM signature applied by list server

That might be a start toward a real solution that solves both sets of 
problems.

Then again - it's late, I'm in the middle doing my taxes - this might 
not make any sense at all.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: [email-masked]
Date: Sun, 13 Apr 2014 19:48:15 -0700 (PDT)

> > that you lose information (the sender's address) if the list wants to operate a
> > policy of "Reply goes to list".  You can then assure that DKIM signatures are
> > valid and set up SPF, etc.  This also has the effect of letting you operate
> > through the various cloud email platforms that try to validate sender
> > addresses.

> left of the @ sign? The rub with DMARC/SPF/DKIM is the domain itself,

No, the rub with DMARC in this case is the choice of a p=reject policy by
a site that doesn't meet the requirements for its use.

> message satisfies the anti-spam tools.

The From: identity is NOT preserved. There isn't an user agent in the world
that would know how to deal with this. So when people reply, their message
bounces.

Of course there are other tricks you can play, such as making an address that
actually works. But while this trick works for things like SRS, in the case
of a user-visible address, it makes a mess.

> MUAs could then be adapted to

Uh huh. Even assuming you could get some traction on this with user agents - a
type of software collectively notorious for being slow to adapt, implement, and
update pretty much everything, you then have to get this deployed quickly to do
any good.

> discussion into solutions instead of griping),

You're not being generous, you're being inaccurate. And even if this was
accurate, you don't call for a change to every MLM and every UA in the world to
address a completely inappropriate policy choice.

> and given that mailing

Riiight. Penalize longstanding practice on the basis of traffic percentages.

By that measure, spam wins.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sun, 13 Apr 2014 20:13:19 -0700

On 4/13/2014 7:49 PM, John Levine wrote:
> Yes, that's the 1980s percent hack.

1979, to be precise, for MMDF's relaying telephone/Arpanet mail with the 
original funding agency, the Army Materiel Command, and then the NSF's 
CSNet.  It was difficult to find a character that made any intuitive 
sense and wasn't already taken.

As an overall construct, in this case, it might work pretty well.  It 
preserves all of the original address in a way that is easily 
machine-parseable.

It treats the list engine as a kind of gateway.  This means that a reply 
to that address will show up at the list host and needs to be relayed to 
the intended recipient.  While a bit inefficient -- and probably will 
emerge as an attack vector (sigh) -- it's a plausible mechanism.

d/

---

From: "John R Levine" <[email-masked]>
Date: 13 Apr 2014 23:28:52 -0400

> intended recipient.  While a bit inefficient -- and probably will emerge as 
> an attack vector (sigh) -- it's a plausible mechanism.

Right -- something is seriously wrong with DMARC as used if we need to 
invent new phish syntaxes to work around it.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Apr 2014 23:44:15 -0400

--On Sunday, April 13, 2014 23:28 -0400 John R Levine
<[email-masked]> wrote:

>> intended recipient.  While a bit inefficient -- and probably
>> will emerge as  an attack vector (sigh) -- it's a plausible
>> mechanism.
> 
> Right -- something is seriously wrong with DMARC as used if we
> need to invent new phish syntaxes to work around it.

Sadly, there are a non-trivial number of MTA installations whose
implementers or operators, having discovered that they had not
seen a legitimate use of the percent hack in years, decided that
they were about as likely to appear in legitimate messages as
source routing and dealt with them accordingly.  Put more
simply, a "%" in a local-part may be least as likely to get a
message rejected or dumped as a badly specified DMARC record, so
the one is really not a very good cure for the other.

    john

---

From: "John R Levine" <[email-masked]>
Date: 14 Apr 2014 00:10:25 -0400

> the one is really not a very good cure for the other.

Since the percent hack became a famous vector for open relay abuse, so we 
all stopped honoring it.  A lot of MTAs still reject anything with a % 
saying something like no more source routing.  Mine does.

So this would require inventing something with the same semantics as the 
percent hack, but a different syntax.  Perhaps we can use an exclamation 
point.

Regards,
John Levine, [email-masked]
Please consider the environment before reading this e-mail.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 14 Apr 2014 05:11:29 +0100

On 14 Apr 2014, at 02:59, Doug Barton <[email-masked]> wrote:
> Meanwhile, I'm still not proposing that we train users, or even anti-spam software to "recognize" or "validate" mailing list addresses. What I'm proposing is a way to send mail from a list with From: @domain-of-list.tld so that it can pass DMARC/SPF/DKIM, and allow the left side of the @ sign to identify the actual sender of the message.

I agree.  In fact, I'm resigned to it already.  OTOH, you'll find the idea unpopular around here. :)

FWIW: I really do believe it is a great shame that DMARC misplaces the burden so profoundly.  Also, I've stopped caring--the fact is that given the choice of:
1.  Authenticate every message from everybody without discrimination, at the cost of making mailing lists a lot less like they were in the Good Old Days (™) and breaking a ton of compatibility
2.  Authenticate only some messages, discriminating personal use from business use (and sending conflicting messages about the trustworthiness of the From: field to regular users) but making mailing lists from 1995 shine
I (and I expect lots of people) choose option 1.

We only need to upgrade the mailing list servers.  The people who run those are supposed to be competent--they can probably manage to upgrade to supported software, or patch what they have.  Mailing lists aren't popular any more anyway.  And this is a golden opportunity to bring some trust into Internet mail.  Let's do it.

Cheers,
Sabahattin

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Apr 2014 00:34:37 -0400

--On Monday, April 14, 2014 00:10 -0400 John R Levine
<[email-masked]> wrote:

>> Sadly, there are a non-trivial number of MTA installations
>> whose implementers or operators, having discovered that they
>> had not seen a legitimate use of the percent hack in years,
>> decided that they were about as likely to appear in
>> legitimate messages as source routing and dealt with them
>> accordingly.  Put more simply, a "%" in a local-part may be
>> least as likely to get a message rejected or dumped as a
>> badly specified DMARC record, so the one is really not a very
>> good cure for the other.
> 
> Since the percent hack became a famous vector for open relay
> abuse, so we all stopped honoring it.  A lot of MTAs still
> reject anything with a % saying something like no more source
> routing.  Mine does.

Exactly.

> So this would require inventing something with the same
> semantics as the percent hack, but a different syntax.
> Perhaps we can use an exclamation point.

I suppose the correct response is "bang, bang, bang,..."

But this takes us back to Ned's point (or at least my
interpretation of it): it is lots easier to fix a bad DMARC
config, ignore restrictive DMARC specifications, or even to
abandon DMARC entirely, than it is to believe that we can
upgrade every MTA and MUA on the network to start accepting
percent hacks, bang paths, or the syntax characters used to
denote them, again.  Or any other strange local-part syntax
anyone is likely to come up with, e.g., perhaps we could use
plus signs, hyphens, or appropriately-escaped backslashes.  Or
we could steal "/" and "=" back from X.400 gateways.  Right.

   john

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 00:41:40 -0400

>>> left side of the @ sign to identify the actual sender of the message.

Sure would be nice if current mailers still recognized bang paths -- 
rewrite
From: [email-masked]
to
From: yahoo.com!user

Sigh...

Miles Fidelman

---

From: Doug Barton <[email-masked]>
Date: Mon, 14 Apr 2014 01:08:00 -0700

>> reject anything with a % saying something like no more source

Perhaps my suggestion to use the percent sign dragged in some baggage I 
wasn't intending. To be clear, I wasn't suggesting that receiving 
systems do anything special with the address, only that we establish a 
convention/standard for how to encode the real address of the sender for 
mail sent through mailing lists. It could at least by visually inspected 
by recipients, and in theory MUAs could learn to deal with it for 
display and/or reply purposes. If a ! works better than a % to separate 
the sender's address from the list address that's great.

For those that are skeptical of MUAs actually doing this, I agree. 
However in recent memory a non-trivial number of modern MUAs have picked 
up parsing of list headers sufficiently to make "reply to list" buttons 
a reality. So not all hope is lost here.

> we could steal "/" and "=" back from X.400 gateways.  Right.

Well + is out, since that's used by various local filtering solutions.

But your point is well taken ... the "right" answer may be to fix or 
discard DMARC, I honestly don't know. But in a world where DMARC is here 
to stay, or if not DMARC then some other anti-spam solution that breaks 
mailing list forwarding; and in that same world where mailing list 
traffic is negligible (and therefore the cost of breaking mailing lists 
is in the noise compared to the benefits of deploying said anti-spam 
solution) it's incumbent on the mailing list software folks to solve 
this problem.

Doug

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Apr 2014 05:14:48 -0400

> Well + is out, since that's used by various local filtering

Doug, I think you are missing my, and probably John Levine's,
attempts at humor.   Let me spell it out:

The point was the "+" is used in local filtering and, perhaps
more generally, as subaddresses with all sorts of applications.
Both "%" and "!", along with <@a:x@y>, were, at different points
and gateways to different systems, mail routing mechanisms that
are now sufficiently deprecated and/or rare that many
intermediate MTAs will singly reject or drop messages containing
them.  "/" and "=" were used on the local part of addresses
bound for, or coming from, X.400 gateways and many systems will
reject (or possibly) drop messages with local parts in which
they appear but that don't conform to that gateway syntax...
except that "/" may also designate delivery to a file and "//"
may be a piece of ancient JCL. 

It isn't just the MTAs: Some POP and IMAP client MUAs will trash
this stuff too.  As with the MTAs, using these sorts of trick
conventions without disrupting the existing mail systems,
including those that don't pay any attention to DMARC or DKIM
headers and hence are unaffected by the problem, requires that
everything be upgraded and upgraded more or less on a flag day
basis.  

There is a strong rule in RFC 5321 and its predecessor
forbidding anything but the final delivery system from rewriting
a local-part and it is there precisely because one doesn't know
what sorts of conventions and indicates were begin used there. 

The bottom line is that trying to work around this by a trick
syntax convention is really hard, unlikely to succeed, and quite
likely to result in legitimate messages disappearing and/or
breaking existing conforming systems.  

> But your point is well taken ... the "right" answer may be to
> fix or discard DMARC, I honestly don't know. But in a world
> where DMARC is here to stay, or if not DMARC then some other
> anti-spam solution that breaks mailing list forwarding; and in
> that same world where mailing list traffic is negligible (and
> therefore the cost of breaking mailing lists is in the noise
> compared to the benefits of deploying said anti-spam solution)
> it's incumbent on the mailing list software folks to solve
> this problem.

I'm going to risk more humor and suggest that everyone who
believes that mailing list traffic is negligible and the cost of
breaking them is in the noise should be immediately unsubscribed
from all IETF-related lists, including this one.

best,
    john

---

From: S Moonesamy <[email-masked]>
Date: Mon, 14 Apr 2014 00:38:28 -0700

Hi Alessandro,
>Please feel free to amend that page at your leisure.

"Big, popular brands are often used in phishing and scam email 
attacks and I'm sure you've seen some of them first hand" [1].  DMARC 
is a technology that provides brand protection.  Let's say that you 
work for cs.helsinki.fi.  cs.helsinki.fi currently publishes a policy 
to protect its brand.  If you use that domain name to send a message 
to [email-masked], cs.helsinki.fi will reject that message.  Several 
big companies will also reject that message.

The suggestion is to have the ietf.org mail service rewrite the 
domain part in the "From:" header as cs.helsinki.fi.invalid.  The 
ietf.org mail service is not doing that at the moment.  The mail 
service does not have to do that as the collateral damage is 
considered as acceptable.  The rewrite will cause other problems.

Email is like the Titanic.

Regards,
S. Moonesamy

1. 
http://www.symantec.com/connect/blogs/introducing-dmarc-validation-email-securitycloud

---

From: <[email-masked]>
Date: Mon, 14 Apr 2014 12:20:57 +0100

But DMARC is email authentication best practice.

Sure, some legacy email things are having some minor teething problems with it,
but it's clearly the way to go. Because it introduces authentication.

Now all the spammers will have to open their free yahoo accounts first, before
sending email! That's a great step forwards!

Security! Best practice!

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of John R Levine [[email-masked]]
Sent: 14 April 2014 04:28
To: Dave Crocker; IETF general list
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Apr 2014 07:23:49 -0700

> what sorts of conventions and indicates were begin used there.

Just to avoid possible confusion about the implications of the above:

      Mediators, like mailing lists, take final delivery and post a new 
message.  In formal terms, it's legitimate for them to create a 
different rfc5322.From field, including one that looks like some sort of 
'rewrite' of the one used by the original author.

d/

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Apr 2014 10:37:12 -0400

--On Monday, April 14, 2014 07:23 -0700 Dave Crocker
<[email-masked]> wrote:

>> forbidding anything but the final delivery system from
>> rewriting a local-part and it is there precisely because one
>> doesn't know what sorts of conventions and indicates were
>> begin used there.
> 
> 
>       Mediators, like mailing lists, take final delivery and
> post a new message.  In formal terms, it's legitimate for them
> to create a different rfc5322.From field, including one that
> looks like some sort of 'rewrite' of the one used by the
> original author.

Yes.

     john

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 11:09:01 -0400

Doug Barton wrote:

<snip>
> discard DMARC, I honestly don't know. But in a world where DMARC is 
> here to stay, or if not DMARC then some other anti-spam solution that 
> breaks mailing list forwarding; and in that same world where mailing 
> list traffic is negligible (and therefore the cost of breaking mailing 
> lists is in the noise compared to the benefits of deploying said 
> anti-spam solution) it's incumbent on the mailing list software folks 
> to solve this problem

Is it perhaps also incumbent on the folks promulgating DMARC (and its 
predecessors, and its sure-to-be successors) to work cooperatively with 
mailing list developers, rather than taking the position "nope, we break 
mailing lists, not our problem?"

I'm kind of coming to the conclusion that what we need to be looking at 
is defining an SMTP extension that addresses BOTH sets of concerns - and 
doing so in a cooperative manner that engages not just the community 
behind DKIM and DMARC, but also the developers and operators of mailman, 
sympa, majordomo, listserv - and ideally the sendmail, postfix, exim, 
qmail community.

Dare I suggest that this calls for an IETF working group?

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 11:10:50 -0400

> from all IETF-related lists, including this one.
But then how could the rest of us yell at them (excuse me, educate 
them)?    :-)

Miles

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 11:38:41 -0400

You really need to use <sarcasm></sarcasm> tags - my first reaction was 
a knee-jerk "says who?"

Miles

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 14 Apr 2014 16:53:05 +0000

First an introduction, I've been active in IETF email and email authentication working groups (As well as in other forums) for quite a number of years but have not been active in IETF from an organizational perspective. I was recently given a heads up about the discussion on the IETF list and joined as well as reviewed the archives related to this discussion. I recognize a number of participants here from other arenas although the majority of participants are not familiar to me. Full disclosure:

1)  I represent my organization as a member of DMARC.ORG but I do not speak on behalf of DMARC.ORG;
2) My comments here unless otherwise specifically stated represent my own opinions and are not a statement representing my employer.
3) While I currently moderate various mail lists, I do not administer them from a technical perspective, although I have in the past.

I'd like to also provide to a blog post of mine on CircleID from 2009 - http://www.circleid.com/posts/20090414_thoughts_on_future_of_email_authentication/ as well as a response from Dave Crocker - http://www.circleid.com/posts/20090422_thoughts_on_email_authentication_trust/. I believe these are as relevant to the discussion today as they were back then (pre-DMARC). There are not simple issues involved despite some of the pronouncements I've seen and there are not likely to be simple solutions other than local policy ones that work locally.

Additional Comments in-line.

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Miles Fidelman
> Sent: Monday, April 14, 2014 11:09 AM
> To: [email-masked]

DMARC has been shown to work extremely well for specific implementations in terms of mitigating direct domain abuse. The DMARC specification was derived from private-channel arrangements between some senders and mailbox providers that started developing in roughly the 2007 timeframe. The impetus for DMARC (and predecessor efforts) was to leverage what was essentially a set of private relationships that were working to create an open standard that would be available for anyone to implement, regardless of size. Mail Lists were identified as a potential issue but the initial set of sending domains did not involve domains with end users and in all of the efforts, this was considered an edge case.

My own analysis - for internal consumption within my organization - which dates back to 2004 following the FTC email authentication workshop, the FTC anti-spam workshop and the DKIM "organizational" dinner that followed, was that if email authentication gained any sort of traction in the wild there would be increasing pressure on domains such as ours (greeting cards/social expressions) and Mail Lists, which did not conform to whatever email authentication standards evolved. If we were going to change our practices, I preferred to do so in a planned manner rather than as a result of a change forced by someone else's decision that would force us to react in a short timeframe and under the gun.

This was one of the reasons that we changed our organizational practices from spoofing (yes, I know that Dave Crocker objects to this term but until we have a better one that gains a consensus I will continue to use it) to sending mail using our own website domains as of the end of 2007/beginning of 2008 depending on the website domain.

> mailing lists, not our problem?"

The fact is that a vocal constituency led by John Levine made it extremely clear that MLMs were out of scope and there was zero interest on the part of the MLM community in discussing ways in which MLMs could be made to work in an email authentication framework even if there were any MLM operators willing to do so. His stated solution has been and continues to be that list operators should drop any participants who post from a domain publishing p=reject and to prevent any new participants from joining from a domain that publishes p=reject. The record is quite clear on this and is available to anyone who wishes to peruse email archives, blog posts, etc. I view this as local policy and up to the list operator. I'm not confident how well this will ultimately work for many organizations the operators manage lists for. Just to be clear, the preceding is more of a question than an assertion.

This was also a point of contention within the DKIM working group with regard to ADSP and if memory serves me correctly it even came up earlier in the MARID working group as part of the discussion surrounding SenderID and the use of the "Sender" field. I don't intend my statements to lay blame or be pejorative. It is what it is. The folks pursuing email authentication standards and practices publicly noted the potential issues and focused on other areas. It was NOT a position of "nope, we break mailing lists, not our problem?", it was a position of not getting into a painful fight over something that many viewed as an edge case while continuing to pursue the stated email authentication goals. I was personally willing to kick the can down the road and respect the MLM operator position as expressed by John and others.

I also note a comment in another IETF thread:  Re: "why I quit writing internet standards". The comment is: "For instance, had DMARC proponents and/or Yahoo, spent some time making sure that there was some running code for mailing list use, life would be better." My response is that if the MLM community, as led by John Levine, had expressed an interest (rather than a stone wall effort) in finding ways of making MLMs compatible then there just might have been running code available at an earlier point and yes, life would currently be better. If the position that John has taken and publicly advocated does not represent the MLM developer and operator community position then I'd appreciate folks speaking up because that is the only position which has been communicated - and very stridently. Again, I am NOT advocating that MLM developers and operators must change. I am simply stating that no rational person pursuing email authentication standards and practices development would willingly walk into this buzzsaw absent an expression of interest on the part of MLM developers and operators.

> I'm kind of coming to the conclusion that what we need to be looking at is
> defining an SMTP extension that addresses BOTH sets of concerns - and
> behind DKIM and DMARC, but also the developers and operators of
> mailman, sympa, majordomo, listserv - and ideally the sendmail, postfix,
> exim, qmail community.
> 

I don't know whether it is possible to find a solution by modifying current implementation practices or if there is a need for an SMTP extension. Franck Martin has posted in a few places a list of MLMs and how they can work (depending on version, configuration, etc) in a DMARC/email authentication context (I don't believe he has done so here). I have not looked into the specifics of the MLM issue deep enough to make any meaningful comments as to what might be done, if anything. I'm also not interested in getting involved in such an effort if there is a vocal constituency within IETF claiming that any such discussion or effort is an attempt to force MLM developers and operators to change how MLMs function and operate. My personal ox isn't getting gored here and I'm not that much of a masochist that I would choose to engage in such a process under those circumstances.

> Dare I suggest that this calls for an IETF working group?

Suggest away but the notion of such a group, unless well wrangled and with a well-defined charter, brings back memories of the MARID working group and its outcome.

> Miles Fidelman

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 10:26:44 -0700

> mailing lists, not our problem?"
The DMARC proponents did engage mailman.   Version 2.1.16 includes support
for a setting that makes the operation of the list DMARC-friendly, though
likely in a way some people will find unpalatable.  Either way, it was not
done entirely in a vacuum.

> defining an SMTP extension that addresses BOTH sets of concerns - and doing
> so in a cooperative manner that engages not just the community behind DKIM
> and DMARC, but also the developers and operators of mailman, sympa,
> majordomo, listserv - and ideally the sendmail, postfix, exim, qmail
> community.
>
I mentioned in another thread that the DMARC people did come to the IETF to
ask for a working group to complete development of the work on the
standards track.  This request was denied on the grounds that DMARC was
essentially already done, and thus the IETF had nothing engineering-wise to
contribute.  There were also too few people that were not already DMARC
proponents that would commit to working on it.

(And as I said on that other thread, I'm happy to stand corrected if I've
mischaracterized any of that.)

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 10:28:51 -0700

On Sun, Apr 13, 2014 at 7:57 PM, Miles Fidelman
<[email-masked]>wrote:

>
> It strikes me that the real way to address some of these issues is to add
> a few new headers to SMTP - to get rid of the overloading of the From: and
> Reply-to: headers associated with mailing lists.  An SMTP extension that
> would absorb some of the well-known and well-understood functions of list
> software.
>
> [...]
>

I made that same suggestion on a different list.  It seems as if that
suggestion was made long ago and the debate reached "religious"
proportions.  One of the usual answers emerged, which was that it'll take
forever to get this deployed with sufficient ubiquity as to be helpful.

I'm guessing that means we shouldn't try.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 10:30:42 -0700

> perhaps someone could set this up.

The DKIM WG discussed this idea in RFC 6377.

-MSK

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 13:57:58 -0400

Murray S. Kucherawy wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Is it perhaps also incumbent on the folks promulgating DMARC (and
>     its predecessors, and its sure-to-be successors) to work
>     cooperatively with mailing list developers, rather than taking the
>     position "nope, we break mailing lists, not our problem?"
>
>
> The DMARC proponents did engage mailman.   Version 2.1.16 includes 
> support for a setting that makes the operation of the list 
> DMARC-friendly, though likely in a way some people will find 
> unpalatable.  Either way, it was not done entirely in a vacuum.
>
>
>     I'm kind of coming to the conclusion that what we need to be
>     looking at is defining an SMTP extension that addresses BOTH sets
>     of concerns - and doing so in a cooperative manner that engages
>     not just the community behind DKIM and DMARC, but also the
>     developers and operators of mailman, sympa, majordomo, listserv -
>     and ideally the sendmail, postfix, exim, qmail community.
>
> I mentioned in another thread that the DMARC people did come to the 
> IETF to ask for a working group to complete development of the work on 
> the standards track.  This request was denied on the grounds that 
> DMARC was essentially already done, and thus the IETF had nothing 
> engineering-wise to contribute.  There were also too few people that 
> were not already DMARC proponents that would commit to working on it.
>
> (And as I said on that other thread, I'm happy to stand corrected if 
> I've mischaracterized any of that.)
>
> -MSK

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 14:08:32 -0400

Murray S. Kucherawy wrote:
>     It strikes me that the real way to address some of these issues is
>     to add a few new headers to SMTP - to get rid of the overloading
>     of the From: and Reply-to: headers associated with mailing lists.
>      An SMTP extension that would absorb some of the well-known and
>     well-understood functions of list software.
>
>     [...]
>
>
> proportions.  One of the usual answers emerged, which was that it'll 
> take forever to get this deployed with sufficient ubiquity as to be 
> helpful.
>
Can anybody comment on the process by which mailing list control headers 
(RFC 2919 and 2369) were coordinated?  Seems like there might be some 
lessons to be learned.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 14:46:59 -0400

Murray S. Kucherawy wrote:
> were not already DMARC proponents that would commit to working on it

Thanks for the history Murray.

Does this, perhaps, illuminate a flaw or failing in the way IETFs 
effects its role as the Internet's official standards body?  The more so 
that it's not stepping in after the fact to help clear up this mess?

I do wonder if there's a related case study in the way that RSS evolved 
into Atom - a case where outside work, and conflicts within it, ended up 
being worked under the IETF aegis?  (Sort of  shame that Atom has not 
become more popular.)

Miles

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 11:55:05 -0700

On Mon, Apr 14, 2014 at 11:46 AM, Miles Fidelman <[email-masked]
> wrote:

> Does this, perhaps, illuminate a flaw or failing in the way IETFs effects
> its role as the Internet's official standards body?  The more so that it's
> not stepping in after the fact to help clear up this mess?
>

Possibly.  I confess I heard the reasons for rejecting the request, but I
still don't fully understand them.

> being worked under the IETF aegis?  (Sort of  shame that Atom has not

I'm not familiar with the story of RSS, but I do know that XMPP and DKIM
are held up as cases where work was started externally and then brought
into the IETF and finished, so there are cases where it is indeed palatable
to the powers-that-be.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Mon, 14 Apr 2014 12:18:33 -0700

Hi Miles,
At 11:08 14-04-2014, Miles Fidelman wrote:
>Can anybody comment on the process by which mailing list control 
>headers (RFC 2919 and 2369) were coordinated?  Seems like there 
>might be some lessons to be learned.

I submitted draft-moonesamy-rfc2369bis-04 [1] and 
draft-moonesamy-rfc2919bis-04 [2] in 2012.  Due to difficulties in an 
IETF working group I did not have any time left to focus on those 
drafts.  The process is to get one of the Applications Area Director 
to sponsor the draft.

Regards,
S. Moonesamy

1. http://tools.ietf.org/html/draft-moonesamy-rfc2369bis-04
2. http://tools.ietf.org/html/draft-moonesamy-rfc2919bis-04

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Apr 2014 08:39:48 +1200

Murray,

On 15/04/2014 05:26, Murray S. Kucherawy wrote:
...
> likely in a way some people will find unpalatable. 

Please tell us more about that.

    Brian

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 14 Apr 2014 17:00:59 -0400

>From what I can tell, it has an option which you can replace the From
field with the original sender's from field with the mailing list's
e-mail address.   i.e., instead of:

From: Brian E Carpenter <[email-masked]>

it would instead be;

From: IETF <[email-masked]>

Any SPF or DKIM fields would also get stripped, and the original from
field would be moved elsewhere (it's not clear from reading the
description whether it's to some other header field, i.e.,
"X-Original-From" or to the body of the e-mail.

The solution I would prefer is one where mailman look up the DMARC
record, and if it's p=reject, it could rewrite the email from:

From: Brian E Carpenter <[email-masked]>

to something like:

From: Brian E Carpenter <[email-masked]>

(or maybe instead of yahoo.com.INVALID, it should be "yahoo.com.BREAKS.MAILING.LISTS" :-)

    	  	     			   	  - Ted

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 17:01:59 -0400

Mike,

Thanks for the history lesson.  It does seem to highlight some 
brokenness in the process, though.

Miles

---

From: Dave Cridland <[email-masked]>
Date: Mon, 14 Apr 2014 22:08:55 +0100

On 14 April 2014 18:26, Murray S. Kucherawy <[email-masked]> wrote:

> I mentioned in another thread that the DMARC people did come to the IETF
> to ask for a working group to complete development of the work on the
The DMARC folk came to the IETF to have a rubber stamp put on their work,
and pretty explicitly stated that no substantive changes were acceptable,
and that change control would de-facto remains with the DMARC consortium.

So nobody who wasn't already "in the club" was really invited.

Feel free to go review the quite extensive discussion almost exactly a year
ago, but it includes suggestions that the DMARC group really only wanted
the IETF to polish the document's text a bit, but that this was rejected.

So no, I dispute very heavily that the DMARC people ever came to the IETF
to "complete development of the work"; there were explicit statements at
the time that they came to have the document wordsmithed without changing
the protocol at all.

The discussion (that I read at the time; there may be more) is all in the
apps-discuss archives.

Dave.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 14:27:09 -0700

> So nobody who wasn't already "in the club" was really invited.

I understand that's how the move was interpreted.  We spent a lot of time
arguing about how to word the charter so that changes were restricted only
to what was necessary versus wholesale changes that caused serious and
unjustified disruption to the installed base, etc. etc.  A lot of work has
been derailed by cracking base specs wide open in the past (think 2821 and
2822, for example).  It was the same argument under which DKIM and XMPP
were brought to the IETF, but in the case of DMARC case the two sides
couldn't agree on exactly how to do it.

One of the very specific items that was on the proposed charter was dealing
with the question of how to integrate DMARC with mailing lists.  This was
called out very early on as an open issue, as were some other important
ones:

http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

-MSK

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2014 21:49:49 -0000

>The fact is that a vocal constituency led by John Levine made it extremely clear that MLMs were out of scope
>and there was zero interest on the part of the MLM community in discussing ways in which MLMs could be made to
>work in an email authentication framework even if there were any MLM operators willing to do so. ...

DMARC must be in pretty bad shape if its proponents have to resort to
malicious lies like this.  It saddens me that Mike, who I used to
consider a friend, would do so.

My position has always been perfectly clear: mailing lists are not
broken, they provide a significant service to individual Internet mail
users, and it is not our job to spend time and money to solve other
people's problems.  DMARC, like all of its predecessor authentication
schemes, has a model of the way people send mail that describes much
but not all of the actual mail people send.  There are an awful lot of
ways that people send mail, so this shouldn't come as a surprise to
anyone.

The invariable next step is that some of the proponents of the scheme,
rather than recognizing and admitting to its limitations, declare that
the mail the scheme can't describe is bad and must be eradicated, with
the term "forged" often misused.  People who have been around long
enough will remember when the SPF crowd demanded that everyone stop
forwarding mail, or a few people wanted to apply strict DKIM ADSP to
everything.  Mailing lists are the most obvious sending scenario that
DMARC doesn't describe, but it's far from the only one.

I have always said that DMARC is useful for a lot of mail, such as the
"spam cannon" stuff (a comment on the volume, not necessarily the
character) that Mike's employer sends, or that Paypal and banks send.
As we have seen, it fails miserably for domains with non-employee live
users.

Without exception the ways proposed to change MLMs to "to work in an
email authentication framework" have involved removing useful features
added over the decades that our users use and like, so it also
shouldn't be a surprise that we're not interested in bowdlerizing our
service to solve their problem.  We also note that many of the
proposed solutions are overcomplicated and unlikely to work in
practice (original-authentication-results) or just plain won't work
(turning off all subject tags, message footers, and other message
modifications.)

If the DMARC crowd were interested in being good net citizens, there
is a way to deal with DMARC's limitations that is straightforward but
not free: whitelisting.  Most of the lists I see sign their mail, and
they generally use static IP sending addresses, so they're not hard to
characterize.  The set of mailing lists and other legitimate mail
sources that DMARC doesn't describe is not enormous, and it should be
possible to develop shared whitelists for them, if someone were
willing to pay for doing so.  (This is a much smaller problem than
trying to whitelist all "legitimate" mail.) If the list-whitelist
group said that lists need to sign their mail or use an unshared IP to
get whitelisted, you would find little resistance, both because most
of us do that already, and because it doesn't ask us to make our lists
worse for our users.

Unfortunately, we've seen no willingness to spend their money to help
us solve their problem, and far too much of do it our way or else,
because we are bigger than you are.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2014 22:00:17 -0000

>Please tell us more about that.

It turns it into a pure forwarder, no subject tags, message footers,
or anything else that might break a DKIM signature.

Of course, even if you do that, it still won't solve the problems that
DMARC causes.  Consider, for example, a Yahoo mail user who prefers
the Gmail interface, so has set up Gmail to collect her Yahoo mail,
and sends her mail from Gmail using her existing Yahoo address.  Gmail
does COI confirmation before letting you use your other outgoing
address, no forgery allowed.  Yahoo provides POP and IMAP service, so
this is clearly something Yahoo anticipated.

As I said in my prior screed, the only way to un-break DMARC is to
whitelist the exceptions.

R's,
John

---

From: Dave Cridland <[email-masked]>
Date: Mon, 14 Apr 2014 23:02:32 +0100

> couldn't agree on exactly how to do it.
Actually, you specifically stated that it was different. DKIM had quite low
deployment, you said - and that in itself was DomainKeys rather than DKIM
per-se. DMARC had, you said, 60% of the mailboxes covered already. Changes
just weren't practical, you said - deployment was already a fact. In fact,
you rejected the phrases used in both DKIM and XMPP's charters, saying they
weren't suitable.

Scott Kitterman said it seemed like the DMARC people wanted just
wordsmithing; Dave Crocker said that was, indeed, what they wanted, but "at
least one AD" had pushed back.

I'm paraphrasing to some degree, but I'll dig out actual links to messages
if you really want.

There's little room for misinterpretation; you and Dave Crocker were, quite
characteristically, very clear and explicit; saying you "understand that's
how the move was interpreted" is a good political phrase, but it was
interpreted that way because you made it very clear that was how it was.

> One of the very specific items that was on the proposed charter was
> dealing with the question of how to integrate DMARC with mailing lists.
> This was called out very early on as an open issue, as were some other
> important ones:
>
Right, but the WG was expected to make it work with mailing lists without
changing it. Tough ask.

Sorry, but given the way in which IETF participants were asked to work on
DMARC, there is absolutely no way you could say that the "DMARC people came
to the IETF to [...] complete development" - it was more or less stated
that development was done and dusted - and the IETF didn't reject it on the
basis that no engineering work remained - the DMARC people rejected any
engineering work happening.

It doesn't actually matter whether you think the reasons behind this were
valid; the fact is that you're putting one heck of a slant on recent
history, and it's not borne out by what's in the archives.

Dave.

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2014 22:02:33 -0000

>From: Brian E Carpenter <[email-masked]>

That's what I do on my lists.  It was pretty easy to add in the shim
that adds the outgoing DKIM signature, and is the least painful thing
I could think of for my mostly non-technical users.

>(or maybe instead of yahoo.com.INVALID, it should be "yahoo.com.BREAKS.MAILING.LISTS"

Now, now, there's no LISTS TLD.  Yet.

R's,
John

---

From: Doug Barton <[email-masked]>
Date: Mon, 14 Apr 2014 15:27:48 -0700

On 04/14/2014 02:14 AM, John C Klensin wrote:
> attempts at humor.

Not so much "missing" it as ignoring it because I'd rather focus on 
finding a solution than on dark sarcasm.

>  Let me spell it out:

... yes, I get all of that, which is why I didn't suggest any of those 
characters. I also specifically didn't suggest ! because I didn't want 
to look like a throwback to UUCP.

> breaking existing conforming systems.

.... which is why I'm suggesting open conversation to try and avoid 
those pitfalls. I would also like to make sure we are scoping the 
problem correctly when you say "working around _this_." John Levine has 
already attempted to derail the concept I'm actually proposing by 
arguing against something I'm not.

And while even the problem I'm actually proposing to solve is hard, 
complaining about it the fact that someone else broke mailing lists is 
definitely not going to solve it.

> from all IETF-related lists, including this one.

John, if you want me off this list just say the word.

Meanwhile, *I* was not suggesting that mailing list traffic is 
unimportant, I get at least a hundred messages a day from various lists, 
and it constitutes the vast majority of my daily electronic communication.

What I AM suggesting however, and I realize that this is a hard pill to 
swallow for many IETF'ers, is that IN THE GRAND SCHEME OF THINGS mailing 
list traffic is inconsequential to large e-mail providers. It's a small 
percentage of the overall traffic they process, and AS A RESULT Yahoo!'s 
calculus clearly reached the conclusion that even though they knew they 
were going to break traffic from some percentage of their users, the 
overall benefit was worth it to them. We may not like to hear that, but 
it IS the reality. If we're going to be serious about the E in IETF 
we're a lot better off starting from the world of reality, rather than 
the world we wish we lived in.

So even if we were somehow able to magically fix DMARC today so that 
list traffic works perfectly with it, tomorrow another anti-spam 
solution is going to come along that is better than DMARC, and mailing 
list traffic as it exists currently won't work with it. The tail will 
not be wagging the dog here, the mailing list software has to be fixed 
if we want to solve this problem.

Doug

---

From: Doug Barton <[email-masked]>
Date: Mon, 14 Apr 2014 15:33:34 -0700

On 04/14/2014 09:53 AM, MH Michael Hammer (5304) wrote:
> The fact is that a vocal constituency led by John Levine made it extremely clear that MLMs were out of scope and there was zero interest on the part of the MLM community in discussing ways in which MLMs could be made to work in an email authentication framework even if there were any MLM operators willing to do so.

Mike,

While I appreciate your version of the history, the above (and the other 
places where you seem to be placing the blame on John Levine) read like 
a bad excuse to me. "John was mean to us" only works if John were 
somehow the elected representative of the MLM Software Cabal, and was 
speaking on their behalf.

We already have evidence that someone from the DMARC community reached 
out to the mailman devs and that resulted in forward motion on a 
solution. That effort should be both applauded and encouraged. Making 
excuses for not conducting additional such outreaches is just ... weak.

Doug

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Apr 2014 17:03:18 -0700

On 4/14/2014 3:27 PM, Doug Barton wrote:
> list traffic is inconsequential to large e-mail providers.

That view is popular, but it's quite wrong.

What /is/ true is that mailing list traffic by users of large mailbox 
providers, through small, independent mailing list providers, is 
probably negligible.  That's the category of primary victim of the 
recent change.

Large email providers come in a few forms.

Some provide mailbox services for gillions of users.  All such services 
focus on social networking, much of which entails some form of mailing 
list or 'group' technology, though often under the guise of different 
packaging.  All of their users are under a single domain name, which is 
always a very attractive target for unauthorized use by abusers.  The 
pressure to limit abuse of the domain is what drove the recent change.

Another major player is the ESP, which does bulk marketing/subscription 
mailings to individuals.  These are, of course, list processing engines.

And so on.

In other words, this space has some complexity and nuance to it, most of 
which is being ignored in the postings over the last week, but all of 
which is actually important to any effort at navigating the challenges 
of fighting abuse while keeping things still useful.

Unfortunately, once all that complexity and nuance is factored in, the 
proper choices and balance still aren't clear...

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 17:11:46 -0700

> Right, but the WG was expected to make it work with mailing lists without

Could it not have been done as an extension?  And as I recall, one of the
proposed paths was to just record and publish DMARC as it is now, and then
get a WG going to help revise it into something that also resolves the
questions in the proposed charter, on the standards track.  This also
failed to gain acceptance.

> history, and it's not borne out by what's in the archives.

I remember what was said.  I'm not trying to be revisionist here.  Rather,
I think I'm trying to remember all the details of a very chaotic
negotiation.

I can't say I blame the DMARC people, or anyone for that matter, for trying
to insulate itself against its work being bogged down for months or longer
rat-holing on things as has been the fate of so many past efforts in the
same area.  (See the thread Wes George started this morning separately.)
Maybe they tried too hard and maybe I even contributed.  But I also think
maybe the IETF needs to rethink its position on taking on work from outside
organizations in the first place, which was one of several road blocks that
came up.  Another is that it was too far along the deployment axis to be
eligible for consideration as new IETF work, regardless of whether the main
document was up for revision.  Yet another is that despite repeated
requests, we couldn't even more than a couple of people (I can remember
four) to submit substantive reviews of the current document; it seemed like
the IETF wasn't interested regardless of the other "regulatory" issues.

I don't have any idea how to retroactively fix all of that, and I suspect
it would be another rat-hole to try.  What I'd really like to talk about is
where we go from here.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Mon, 14 Apr 2014 16:50:08 -0700

Hi Mike,
At 09:53 14-04-2014, MH Michael Hammer (5304) wrote:
>The fact is that a vocal constituency led by John Levine made it 
>extremely clear that MLMs were out of scope and there was zero 
>interest on the part of the MLM community in discussing ways in 
>which MLMs could be made to work in an email authentication 
>framework even if there were any MLM operators willing to do so. His 
>stated solution has been and continues to be that list operators 
>should drop any participants who post from a domain publishing 
>p=reject and to prevent any new participants from joining from a 
>domain that publishes p=reject. The record is quite clear on this 
>and is available to anyone who wishes to peruse email archives, blog 
>posts, etc. I view this as local policy and up to the list operator. 
>I'm not confident how well this will ultimately work for many 
>organizations the operators manage lists for. Just to be clear, the 
>preceding is more of a question than an assertion.

I don't think that there is zero interest from the Mailman community 
(that's my interpretation of the Mailman discussions).  Mailman 
developers do not participate in the IETF.  There is an employee of a 
well-known company who has been arguing for changes to the mailing 
list management software since a long time.  The Mailman patch for 
DMARC was written by Jim Popovitch and Phil Pennock ( 
https://mail.python.org/pipermail/mailman-developers/2013-October/023349.html 
and 
https://mail.python.org/pipermail/mailman-developers/2013-November/023384.html 
).

Mailing list traffic is not significant in comparison with overall 
mail traffic.  At the risk of sounding insensitive there isn't a 
business case for some providers to support mailing list traffic.  I 
would consider John Levine's point about making it out of 
scope.  There's still the problem of what to do about mailing lists.

Regards,
S. Moonesamy

---

From: Douglas Otis <[email-masked]>
Date: Mon, 14 Apr 2014 17:45:45 -0700

On Apr 14, 2014, at 5:11 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> I don't have any idea how to retroactively fix all of that, and I suspect it would be another rat-hole to try.  What I'd really like to talk about is where we go from here.

Dear Murray,

Perhaps the IESG now has more of an open mind regarding risks associated with an "authoritative"  domain responding to a query about a third-party domain impacting the delivery of their users email.  

I'll be happy to re-write the ATPS or ATP draft to offer a simpler, deployable, and functional version able to support aggregated listings.  Brian has already asked that this not be done as an individual submission.  It seems fruitless trying to motivate bulk senders or large ISPs into addressing this problem.  This is something the "email community" needs to solve.  At most, it should involve a simple reference to a ATP listing domain.

1) make use of existing authentication schemes, not just DKIM.
2) always generate consistent labels to ensure fewer community conflicts.

Regards,
Douglas Otis

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 20:46:24 -0400

> probably negligible.  That's the category of primary victim of the 

I'm not sure that's true, Dave.

The lists I run, these days, are for things like community 
organizations, parent-teacher groups, churches, and such.  What I find 
is that over half of my subscribers - both in the high-income city where 
I live, and Boston Public Schools (where I used to live) - are coming in 
through yahoo and hotmail accounts, followed by a mix of ISP accounts 
with broadband providers (Comcast, RCN, Verizon in these climes).

Now an awful lot of these folks ALSO have work email, and a lot of some 
other personal email address - so my guess is that:
- folks who don't do a lot of email, sign up for a yahoo or hotmail 
account because it's free and easy
- more sophisticated folks, sign up for a free account to segregate 
truly personal, and work related email from lists, and commercial sites

This also doesn't seem to be limited to more settled folks - all three 
of my college/just-post-college kids have either a hotmail, yahoo, or 
gmail account (1 each) - again, probably because it's free.  They use 
accounts on one of my servers for more official things like job 
applications.

Now, given that pretty much every parent with a kid in the local schools 
is on a parent-teacher email list; and everyone in the two churches I 
support is on their respective email lists; and there are very active 
neighborhood level parent and community lists - there are an awful lot 
of email list users around here.  I expect the same is true elsewhere 
(how many people reading this are on a school or church related list, 
not to mention various technical lists?).  And I note that those lists 
are all quite active.

Now, the list activity is still dwarfed by spam - but once you filter 
out the spam, and general commercial crap, I expect what's left in most 
people's email is a mix of directly personal, work, email lists, and 
notifications from social network sites.

I could be wrong on this - but I have a pretty good window into email 
use in this corner of the world, and that's what I see.

Cheers,

Miles

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 20:53:00 -0400

S Moonesamy wrote:
> would consider John Levine's point about making it out of scope.  
> There's still the problem of what to do about mailing lists.

Depends on what you mean by "significant."

I'm probably being redundant here, after my previous response to Dave - 
but I expect that once you filter out the 90% of traffic that's pure 
spam, email traffic is a VERY significant portion of what's left.  (For 
that matter, it's probably true of postal mail too.  Most of what comes 
through the slot is junk mail, throw that away and it's a mix of 
personal mail and magazines.)

Not that much different than email being a wart on the side of Internet 
traffic - until you filter out the video.  By transaction count, email 
dwarfs everything else, probably even after discounting for spam.

Now, if you're an ISP or ESP that makes money off of sending bulk email, 
or providing a home for outbound spammers, maybe you don't consider list 
traffic to be "significant."  But if you're an individual email USER - I 
expect that one or two email lists represent the MOST significant part 
of your email stream.

Miles

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 15 Apr 2014 01:21:30 +0000

> From: John Levine [mailto:[email-masked]]
> Sent: Monday, April 14, 2014 5:50 PM
> To: [email-masked]
> Cc: MH Michael Hammer (5304)
> Subject: Re: protecting the Internet from DMARC damage, was perspectives
> 
> >extremely clear that MLMs were out of scope and there was zero interest
> >on the part of the MLM community in discussing ways in which MLMs could
> be made to work in an email authentication framework even if there were
> any MLM operators willing to do so. ...
> 
> malicious lies like this.  It saddens me that Mike, who I used to consider a
> friend, would do so.
> 

John, your position has been absolutely consistent through the years. Your comments below reflect that. Your comments in the IETF-DKIM working group reflected that as well. I'm sorry you no longer consider me a friend but your position has consistently been "we are not broken, now go away". If the world were encased in ambergris that might be a useful position but the world is not. We have disagreed on this for over a decade.

> My position has always been perfectly clear: mailing lists are not broken, they
> provide a significant service to individual Internet mail users, and it is not our
> job to spend time and money to solve other people's problems.  DMARC, like
> all of its predecessor authentication schemes, has a model of the way people
> send mail that describes much but not all of the actual mail people send.
> There are an awful lot of ways that people send mail, so this shouldn't come
> as a surprise to anyone.
> 

How does your statement substantively differ from what I wrote in my previous post? You explicitly state that it is not your problem and it is somebody else's problem. You have been vocal about your position for years and years. You may not like my characterization of your position but that is your position nonetheless. It is not simply that you took that position regarding DMARC but that you have consistently taken that position for ANY discussion regarding potential changes to MLMs for ANY changes that might relate to authentication. Your position has been that the community at large can rely on "your" reputation (the actual example you gave in the SSP discussion in 2008 related to the IETF-DKIM list hosted by Dave Crocker). While you (or Dave) may have an excellent reputation - and I agree that you do despite our differences - that is not the basis for a scalable standard. You assert that lists are not and have not been a vector for abuse. I've seen abuse through lists where a subscriber account has been compromised. Yes it may get addressed by operators, some faster than others. Rather than working to find a model (or expand existing ones) to address the use cases you claim won't work or shouldn't be changed because "we were here first and it works for us", I would assert that it is beneficial to the community to have the discussions to come up with standards and practices that protect end users from abuse. 

> rather than recognizing and admitting to its limitations, declare that the mail
> the scheme can't describe is bad and must be eradicated, with the term
> "forged" often misused.  People who have been around long enough will
> remember when the SPF crowd demanded that everyone stop forwarding
> mail, or a few people wanted to apply strict DKIM ADSP to everything.
> Mailing lists are the most obvious sending scenario that DMARC doesn't
> describe, but it's far from the only one.
> 

You are absolutely correct in stating that DMARC doesn't address mailing lists - because you have staked out a position that mailing lists should not have to change in any way shape or form to deal with any authentication model. That is extremely constraining out of the gate and pretty much ends any meaningful discussion at that point. "How about if we... NO!"

> I have always said that DMARC is useful for a lot of mail, such as the "spam
> cannon" stuff (a comment on the volume, not necessarily the

I haven't pushed for DMARC to be applied to domains with end users but the fact that it "fails miserably" (for some definition of fail) reflects more on a lack of discussion and effort on how it (or other approaches) might work (due to intransigence) rather than the fact that it or some other approach could work.

> added over the decades that our users use and like, so it also shouldn't be a
> surprise that we're not interested in bowdlerizing our service to solve their
> problem.  We also note that many of the proposed solutions are
> overcomplicated and unlikely to work in practice (original-authentication-
> results) or just plain won't work (turning off all subject tags, message footers,
> and other message
> modifications.)
> 

John, abuse is a community problem. I haven't been involved in any of the proposed solutions regarding mailing lists which you mention for precisely the reason that you (As the voice of MLM developers and operators) have made clear that there is absolutely no implementation (other than leave you to your own devices) that is acceptable. I don't count using separate IPs and signing mail emitted by your servers (for domains other than your own) as a meaningful effort. I'm just not the kind of guy who accepts "trust me" as a meaningful anti-abuse solution.

> If the DMARC crowd were interested in being good net citizens, there is a
> way to deal with DMARC's limitations that is straightforward but not free:
> whitelisting.  Most of the lists I see sign their mail, and they generally use
> static IP sending addresses, so they're not hard to characterize.  The set of
> mailing lists and other legitimate mail sources that DMARC doesn't describe is
> not enormous, and it should be possible to develop shared whitelists for
> them, if someone were willing to pay for doing so.  (This is a much smaller
> problem than trying to whitelist all "legitimate" mail.) If the list-whitelist
> group said that lists need to sign their mail or use an unshared IP to get
> whitelisted, you would find little resistance, both because most of us do that
> already, and because it doesn't ask us to make our lists worse for our users.
> 

You have put forward the whitelist (FUSWP - Final Ultimate Solution to the Whitelisting Problem) solution in the face of a variety of proposals. DMARC does not preclude whitelisting by the validating operator. In fact, it specifically provides for local policy overrides, including one for mailing lists. You say it is someone else's (the "DMARC crowd" as you put it) problem. It's kind of like the old saw about truckers thinking they are in the trucking business rather than the transportation business. We are ALL in the email space.

Your solution to mailbox providers with users that implement p=reject is to boot the users off of mail lists and tell them to go find another mail provider. That may work for some lists but there will be significant issues for others. I'm not even going to delve into your comments about lists signing their mail when sending as a domain other than themselves. That discussion has been had multiple times in multiple forums. When presented with a mail list signature on an email purporting to be from a given domain and an assertion from the domain itself that constrains use of that domain, I know which one I'm going to go with as a general rule.

When I think of your church mail list example, the first thing that came to mind is WWJD? The second thing that came to mind is that an organization, whether a church, a university or similar organization, might not be too appreciative if significant donors or volunteers were told by their mail list operator "to take a hike" because the mail list operator is upset by that persons mailbox provider. Whether you like it or not and whether you admit it or not, it is your problem because it is a community problem. As I have stated before, I have not advocated that domains with users should publish a p=reject. I do recognize that those domains may have an interest in protecting their domains from abuse and see DMARC is a potential tool to mitigate direct domain abuse. I say this without personally advocating for it. You have studiously avoided one of the key underlying questions for this discussion and others: Does the owner of a domain have the right to control or limit the use of its domain (or other similar resources)? If not, which 3rd party gets to be the decider? Are there any limits on the 3rd party decider? If so, who gets to set the limits on the 3rd party decider? Be careful, it's a slippery slope.

> Unfortunately, we've seen no willingness to spend their money to help us
> solve their problem, and far too much of do it our way or else, because we
> are bigger than you are.
> 

Look at how you phrased the above. That translates into give us money or we won't make any effort whatsoever. Is it really about money? I truly don't think so. Please provide as a reference your ID for this proposed whitelisting standard in datatracker. Absent specific detailed proposals that would induce someone to sponsor your effort why would anyone give you money for this whitelisting equivalent of FUSSP? Good mailers go bad. Every once in a while bad mailers go good. I'm quite familiar with whitelisting schemes and my personal position is "What have you done to me today?". I don't care what your reputation has been for the last x years if you are emitting badness today. You opened your email stating that "It saddens me that Mike, who I used to consider a friend, would do so." You obviously don't whitelist people so why would you expect people to accept your assertion that you (your maillist) should be whitelisted? I am of course disappointed that you no longer consider me a friend, but if blunt discourse on a difficult subject requires you to do so then I accept that. Readers of this exchange can decide for themselves whether, as you have asserted, I have maliciously lied about you. The archives from IETF-DKIM are available as are the ones for IETF-DMARC and DMARC-DISCUSS. I would also point people to the archives for ASRG as well for a litany of out-of-hand rejection (although I willingly admit that many of the proposals from newly subscribed participants did lack a certain understanding of the problem space).

You may not like my characterization of your position but your position has consistently - over quite a few years - been that MLMs are fine, now go away because it is "your" problem, not mine. That is the essence of your post I'm currently responding to.  It's not a function of "them" being bigger than you. It's a function of you not being willing to have any sort of meaningful engagement with "them" other than on terms you dictate. It's not just large domain owners and corporations struggling with abuse. It's domain owners of all sizes and types. And yes, it's individuals that suffer the consequences of our collective failure to find solutions to real world abuse. I again reiterate that I am not personally advocating that domains with users publish p=reject regardless of impact on others. I will say that the train has left the station and I expect there will be other domains which, in the face of significant abuse, will make similar decisions. Absent alternatives and seeing that similar domains claim that the approach has provided relief for them, this would appear to be a logical choice and not an irrational one.

With each additional domain that makes such a decision your position becomes increasingly untenable. You (and others) might be willing to kick off list participants from such domains if it represents some small percentage of participants but how many list operators will do so if such participants represent a significant portion or majority of participants? Will the organizations that these lists are managed for accept such outcomes? Some will but many won't. They will switch to implementers that allow them to go about their daily activities without it being made painful for them. If a mailing list is configured and nobody is subscribed or participates is it a mailing list? You propose pain as a motivator but you don't seem to recognize that such pain may motivate people and organizations to outcomes other than that which you desire.

I recognize that this is a bitter discussion for some. It could have and should have been a discussion held much earlier and in a different context. That is water under the bridge. As others have asked, where should the IETF and the larger community go from here? Punishing users as a means of getting at a mailbox provider doesn't seem particularly constructive in the long run and as I have indicated above may be somewhat self-defeating. IETF shunning of DMARC may feel good but even John Levine has stated that it has benefits in particular implementation categories (as long as no change is asked of MLMs). A discussion of technical approaches that enable mail lists to participate in authentication approaches for 3rd party domains without losing (significant) functionality might be useful. Are there alternative ways of providing that same functionality? Note that I'm not even being DMARC specific in proposing that. John Levine has proposed whitelisting as a solution. I don't buy into that personally but it might be a useful discussion to have - monetary donations should not be required in order to have a discussion about this.

Apologies to all for this long missive.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Apr 2014 13:36:20 +1200

> I could think of for my mostly non-technical users.

It's also much better than destroying everybody's From field, which rather
defeats the purpose of a mailing list to my mind. OK, Mailman 2.1.16
doesn't actually solve the problem in a useful way. Thanks.

   Brian

---

From: "John R Levine" <[email-masked]>
Date: 14 Apr 2014 21:59:53 -0400

> You are absolutely correct in stating that DMARC doesn't address mailing 
> lists - because you have staked out a position that mailing lists should 
> not have to change in any way shape or form to deal with any 
> authentication model. That is extremely constraining out of the gate and 
> pretty much ends any meaningful discussion at that point. "How about if 
> we... NO!"

The sentence always ends "... spend our own time and money to break or 
remove features our users expect and like to solve your problems", so of 
course the answer is no.

I've never said that lists won't change, I've said that we're not going to 
screw them up to work around your FUSSP.

If you ever made a reasonable offer, I would be happy to talk about it.
But you haven't.

If the DMARC gorillas hired someone (Returnpath? Spamhaus?) to build a 
mailing list whitelist, the goodwill would be enormous and the cost, 
spread among the DMARC group, would be nominal.  But spending your own 
money to solve your own propblems somehow isn't on the table.  We're 
supposed to spend ours, instead.  Are you really surprised this is not 
making you any friends?

R's,
John

---

From: Doug Barton <[email-masked]>
Date: Mon, 14 Apr 2014 19:58:27 -0700

> probably negligible.  That's the category of primary victim of the

Right, which is what we're talking about.

If all my message traffic is on internal only systems (such as the 
social networking you described) then I don't care what my transport 
mechanism is; mail, XMPP, or RFC 1419. It's not going out of my network, 
so I don't even need to use an Internet standard.

So getting back to solving the actual problem at hand ....

Doug

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Apr 2014 23:31:03 -0400

On Monday, April 14, 2014 16:53:05 MH Michael Hammer wrote:
...
> Suggest away but the notion of such a group, unless well wrangled and with a
> well-defined charter, brings back memories of the MARID working group and
> its outcome.

The failure of MARID was entirely legal and political.  At the time the 
working group was summarily closed there weren't major technical issues left 
to resolve.  When you try to mix two groups of people, one almost exclusively 
from a free software/open source background with a large corporation that 
insists on patent licenses that are incompatible with free software/open 
source no amount of wrangling is going to save it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Apr 2014 23:35:48 -0400

On Monday, April 14, 2014 10:26:44 Murray S. Kucherawy wrote:
> > doing

My perception (and it may also be wrong) is that anyone who claimed there was 
work yet to be done was shouted down.  It was either prove there was work to 
be done by going off and doing it on your own, or clearly it was done and no 
more work needed doing.

The DMARC spec has certainly improved since it's been public, but I certainly 
don't think it's done and have said so multiple times.  I'm also willing to 
work on it.

As I said in the other thread, I think the only reason it was perceived as 
done is that the private group that developed the spec declared it done and 
fought against any WG charter language that would have permitted changes to 
the core protocol.    Based on that approach, no wonder it was declined.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 21:58:48 -0700

> screw them up to work around your FUSSP.

It would be great if it were more of a dialog rather than a repeated
exercise in intransigence.  I guess when you're a list, everything looks
like a FUSSP.

Having been involved in things like SPF, DKIM, ADSP, etc. over the years, I
can say that mailing lists always recur as a major obstacle.  "Lists have
been doing what they're doing for N years and they work fine.  You don't
get to mess with them."  That's the mantra.

In DKIM, we even did a whole separate RFC to talk about all the fun ways
lists are a special case.

The specifications of 30 years ago included some neat capabilities for
communication, some of which mailing list servers employ to do what they
do.  I mean, I get that being able to put whatever you want in the From:
field is a feature.  Honest, I do.  But meanwhile, increasingly, bad people
use the very same capabilities to do their hugely expensive harm.  Is it
really the case that the benefit mailing lists (as they are today anyway)
bring to the Internet outweighs the harm of leaving these capabilities wide
open?

There are probably earlier examples, but remember the finger protocol?  In
80s and 90s, it was on, and it was harmless, maybe even useful.  Then it
started to get abused and exploited, so we collectively turned it off
because the damage outweighed the benefit.  That practice has been applied
countless times since, to any service that gets rolled out in any context
you can imagine that then gets discovered and exploited by bad actors: We
fix the vulnerability, or we kill the service.  We don't believe in
"substantial non-infringing use" as a reason to keep something bad online.
I can't think of an instance where that's not the case except email abuse,
because we protect mailing lists, which have enjoyed apparent immunity
despite ever-increasing pain to the victims of that abuse with no solution
in sight.

So why do lists get the privilege of being immutable?  Can't there be some
quid pro quo?  Do the people with the problem also have to come up with the
solution, preferably maintaining the status quo for lists, or could it
maybe be more of a cooperative brainstorming thing?  Is it really totally
inconceivable and unacceptable that there has to be some evolution here?

And before anyone tries to claim it, I'm not saying lists are second class
actors, nor am I making any kind of claim about traffic percentage.  I
would just like to understand when and why they were granted this protected
status in standards work that they appear to enjoy.

-MSK

---

From: Dave Cridland <[email-masked]>
Date: Tue, 15 Apr 2014 08:42:12 +0100

> failed to gain acceptance.

An "incremental and optional" extension which would not require changes to
the deployed software and operational practises. You want an optional
extension which would optionally allow DMARC to traverse mailing lists
usefully when it's optionally deployed? Good one. Can I base it off ACAP?

In fact, I can't find any evidence for willingness to let go of change
control. The closest I can find is a year and a day ago, when you said:

"I'm pretty sure the intent is to publish the current base draft through
the ISE, since it was developed outside the IETF, but if it changes (via
rechartering), move it to the IETF stream.  The latter can obsolete the
former if the timing warrants doing so.  Thus, if the working group is ever
actually cracking open the base draft, it's on the IETF stream."

Note, that's "via rechartering", so the WG was not initially chartered to
change the base spec. The actual proposed charter says it could recharter
in extremis, but that's after two paragraphs explaining why it shouldn't.

> I think I'm trying to remember all the details of a very chaotic
Go read the archives. Refresh your memory.

> I can't say I blame the DMARC people, or anyone for that matter, for
> trying to insulate itself against its work being bogged down for months or
> longer rat-holing on things as has been the fate of so many past efforts in
> the same area.  (See the thread Wes George started this morning
> separately.)  Maybe they tried too hard and maybe I even contributed.  But
> I also think maybe the IETF needs to rethink its position on taking on work
> from outside organizations in the first place, which was one of several
> road blocks that came up.  Another is that it was too far along the
> deployment axis to be eligible for consideration as new IETF work,
> regardless of whether the main document was up for revision.  Yet another
> is that despite repeated requests, we couldn't even more than a couple of
> people (I can remember four) to submit substantive reviews of the current
> document; it seemed like the IETF wasn't interested regardless of the other
> "regulatory" issues.
>
>
It's hard to be interested in doing IETF work on something that wasn't
managed by IETF process, or IPR rules, and was actively marketed as being
done, deployed, and not subject to further change. "Please review our
specification so we can ignore your comments and rubber stamp the result"
is not a tremendously attractive proposition.

I suspect that had the IETF been involved considerably earlier, none of
this would have happened. I'm not really sure how this could have been
fixed, as I've noticed a strong tendency amongst organisations which
control large proportions of the deployed market to assume that minority
viewpoints do not count. The "60% of all mailboxes" fanfare is an example
of this. I've seen similar from browser vendors in WebSocket, and I've no
doubt that the major router vendors play the same card with BGP et al.

Some of this is understandable - expertise and experience do tend to pool
at such organisations - but increasingly I feel that we've lost sight,
somewhere, that - for example - because 60% of the world's mailboxes are
handled by the DMARC cabal, that still leaves 40% who may have somewhat
different needs and requirements from the protocol. Given the expense and
difficulty of IETF participation for smaller organisations and individuals,
it's hard for them to club together and stand up to the 8000lb gorillas.

DMARC is not an IETF standard - you know this, I realise - but there was no
sense from the messages exchanged a year ago that it ever would be an IETF
product in anything more than - perhaps - name.

> it would be another rat-hole to try.  What I'd really like to talk about is
It really depends on whether the 8000lb gorillas are open to letting go of
the change control or not. A year ago they clearly weren't.

Dave.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 15 Apr 2014 09:52:26 +0200

> electronic mail communications.

Ok, I added "temporarily", so it now reads:

   Various workarounds have been proposed to cope with domains that
   publish strict policies unwittingly. For example, a mailing list
   manager should reject posts from authors who use problematic email
   domains. The latter behavior is the most respectful the
   communication protocols as well as the domain owner's will.
   However, it might cause inconveniences in the face of sudden
   policy changes. According to John Levine, a well known mail
   expert, the least intrusive way to temporarily mitigate the damage
   would be to rewrite the From: address in a predictable,
   comprehensible manner, such as the following:

In the preceding "History" section, I appended:

   In April 2014, Yahoo changed its DMARC policy to p=reject, thereby
   causing misbehavior in several mailing lists.[6] DMARC is not yet
   a standard protocol, and currently misses a provision for such
   sudden changes.

Is that more acceptable?

> difficult and IMO, it is far less intrusive than changing the 5322.From.
> 
> The first one is the piece a cake.

Yes

> The 2nd one can be more complex

I think (2c) has to be done politely, in order to allow people the
time to react adequately.

Ale

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Apr 2014 09:11:01 -0400

>From: Brian E Carpenter <[email-masked]>

So, that totals people's address books.

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

---

From: [email-masked]
Date: Tue, 15 Apr 2014 07:51:20 -0700 (PDT)

> forever to get this deployed with sufficient ubiquity as to be helpful.

Suggestion? Try suggestions. I can think of at least four proposals at various
times, and I'm quite sure there have been others. At least one of them, by John
Myers, was written down in a draft.

And the problems with these proposals weren't religious. Rather, the problem
has always been that originator header semantics are already fairly nuanced,
and adding a bunch of them seems to exceed our design abilities. As a result
the discussions bogged down in misunderstandings about minutiae and talking
at cross purposes.

The only discussion I know of in this space that reached "religious
proportions" was the one in the failed mailing list WG.  But that was largely
focused on the "right" way to use existing header fields, not the addition of
new fields. So I don't think that really counts.

> I'm guessing that means we shouldn't try.

OK, for this to work you're going to have to come up with a solution that's
clear and comprehensible, get general agreement on it, publish it, and then get
widespread support for it implemented and deployed in both list processors and
user agents in a fairly timely way.

I'd also say there's a good chance that DMARC will have to be changed in some
way to support it, so that needs to be on the table. And that support needs to
be deployed.

Given these realities, do you think this is worth spending (a probably large
amount of) time doing?

				Ned

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 15 Apr 2014 11:30:47 -0400

> So, that totals people's address books.

But only for yahoo.com users.  Somehow, I have a very hard time
feeling sympathetic about their plight.

If Yahoo isn't going to care about screwing over mailing list
administrators, I'm not sure why I should care about about
inconveniencing Yahoo uesrs.  If they end up moving to some other mail
provider, I'll consider that a bonus.

And if Yahoo is right, and most Yahoo users don't use mailing lists,
then obviously this won't be a problem, right?

						- Ted

---

From: "John R Levine" <[email-masked]>
Date: 15 Apr 2014 11:54:20 -0400

> feeling sympathetic about their plight.

No, it also screws up anyone who wants to correspond with Yahoo users who 
happen to correspond via shared mailing lists.

But in the current environment, it still seems the least bad option.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Apr 2014 09:25:40 -0700

On 4/14/2014 8:35 PM, Scott Kitterman wrote:
> work yet to be done was shouted down.

Given that the exchanges were on an open mailing list, I'm not quite 
sure what that means.

What I am sure of is that I've pressed quite vigorously and repeatedly, 
first on the open dmarc.org mailing list and then on the IETF DMARC 
mailing list, for folk to cite work that needed to be done and to 
develop group support for that work.

What I saw was some individuals suggesting some bits of work, but no 
support developed around it.  (By 'support' I mean more than a few folk.)

Perhaps you can point to specific examples of this 'shouting down' 
happening?

What I also saw was some folk insisting that the charter be vague and 
unconstrained, with no concern for the installed base.

> the core protocol.    Based on that approach, no wonder it was declined.

Changes to the core of a protocol is the essence of de-stabilizing its 
installed base.

Writing a charter that permits de-stabilizing a substantial installed 
base only makes sense when there is a clear and compelling basis already 
known for needing to make such changes.

With respect to DMARC, none has been offered or has developed community 
support.

Writing a charter that permits de-stablilizing an installed base 
covering 60% of the world's email traffic, in the absence of a clear and 
compelling understanding of the need would be irresponsible.

Arguably, the mere existence of such a charter would be de-stabilizing, 
since it means that anyone considering adoption has an excuse to defer 
it to the indefinite future, when the IETF might get around to releasing 
a revision.

d/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Apr 2014 12:46:29 -0400

> feeling sympathetic about their plight.

yes, I take your point.  Let's be clear, it totals my address book for people
who are on yahoo.  I agree that maybe that's tough.

    > provider, I'll consider that a bonus.

+1

    > then obviously this won't be a problem, right?

funny, cause most people I know who have yahoo addresses do so because it
given to them so that they could manage their mailing lists.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 15 Apr 2014 09:23:22 -0700

Hi Miles,
>Depends on what you mean by "significant."

[snip]

>Now, if you're an ISP or ESP that makes money off of sending bulk 
>email, or providing a home for outbound spammers, maybe you don't 
>consider list traffic to be "significant."  But if you're an 
>individual email USER - I expect that one or two email lists 
>represent the MOST significant part of your email stream.

If the choice is to:

   (a) make money

   (b) put effort into what is in the interest of an individual user

What would people actually do?

What I mean by the word "significant" is what will make a corporation 
think thrice before it does anything against the interests of that 
group of people.  There were a lot of messages on the various mailing 
lists where the topic has been raised.  In my opinion there hasn't 
been any results up to now.

Regards,
S. Moonesamy

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 15 Apr 2014 14:48:50 -0400

> happen to correspond via shared mailing lists.

Yes, it means it will be harder to correspond with Yahoo users.  Maybe
their friends who want to talk to those yahoo users will also help
convince them to use another mail provider.

					- Ted

---

From: S Moonesamy <[email-masked]>
Date: Tue, 15 Apr 2014 12:23:44 -0700

Hi Dave,
At 00:42 15-04-2014, Dave Cridland wrote:
>Given the expense and difficulty of IETF participation for smaller 
>organisations and individuals, it's hard for them to club together 
>and stand up to the 8000lb gorillas.

The above is an obvious problem or difficult situation that people do 
not want to talk about.

Publication in the IETF Stream usually entails giving up change 
control.  Sometimes that does not work out well; see RFC 6109.  The 
process is tedious.  It does not have to be like that if people make 
room for agreement.  In simple terms, people can discuss about X for 
the next three years or there can be a short discussion and a 
solution within the next three months.

The summary of the DMARC BoF is at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10138.html 
According to that message there was agreement for the IETF to take on 
the DMARC base specification.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2014 08:21:18 +1200

> feeling sympathetic about their plight.

Also, it isn't really 'total'. At least with my MUA, it's trivial to
edit a To or CC address, or an address book entry; it's an annoyance of course.

Note to spammers: [email-masked], if it exists, isn't me.

    Brian

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 15 Apr 2014 20:30:32 +0000

> From: ietf [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Tuesday, April 15, 2014 3:24 PM
> To: Dave Cridland
> Cc: [email-masked]
> >organisations and individuals, it's hard for them to club together and
> >stand up to the 8000lb gorillas.
> 
> The above is an obvious problem or difficult situation that people do not
> want to talk about.
> 

My experience with regard to working groups is that it is (technically) easy to participate and does not necessarily involve any particular costs. I don't go to IETF meetings but have participated in WG sessions during IETF meetings through jabber. Not the optimal solution but it works. I think that the notion of 8000lb gorillas somewhat misrepresents the situation. Some of the active participants in the working groups I've been involved with continue their involvement even when they change employers. With that in mind, I believe that in many cases it truly is the individual and not the individual as mouthpiece for the organization. I also believe that the 8000lb gorillas have many of the same interests as smaller organizations and individuals even though there are times where interests may diverge. It's also clear to me that there is not uniformity of interests across constituencies within large organizations. It's complex. So let's talk. 

> Publication in the IETF Stream usually entails giving up change control.
> Sometimes that does not work out well; see RFC 6109.  The process is
> tedious.  It does not have to be like that if people make room for agreement.
> In simple terms, people can discuss about X for the next three years or there
> can be a short discussion and a solution within the next three months.
> 
> According to that message there was agreement for the IETF to take on the
> DMARC base specification.
> 

Unfortunately, the operative word is "was". Barry dropped his submission and Murray submitted as informational, so that ship has sailed. What that means for whether a working group is spun up to work on extensions or anything else is beyond me. If DMARC base is informational I would assume that any of the extensions would be informational. I'm not sure what the implications are.

Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 Apr 2014 16:56:50 -0400

>     a standard protocol, and currently misses a provision for such

I think adding temporarily helps and the additional text about DMARC 
certainly helps.

But the problem is YAHOO doesn't want you to do this (rewrite).

Just consider what you are essentially doing:

    Degrading a secured message to a non-secured message.

The whole point of Yahoo moving to a restrictive policy is to force a 
cleanup of their domain usage, to increase its security quality, even 
if it hurts the innocent users who were using their domains in public 
mail list areas.

So I would personally refrain from any product liability risk that its 
ok to "tamper" with their DKIM secured author domain submissions.

Case in point, lets say a real bad message got into the list, 
unsigned, purported from Yahoo, the 5322.From was rewritten and 
distributed to other list users and some of those users were "harmed" 
in some fashion that it worth the effort to sue.   Guess who would be 
at legal fault here?  Not YAHOO. They are legally protected.  The MLM, 
who wistfully and intentionally ignored policy and even went as far to 
break the security, is now at risk.

No, its not silly, and just because I am not a lawyer, doesn't mean we 
don't think about these things in our product development.  In fact, 
it is generally the engineer, us, that has to ask the our lawyers if 
this is ok.  He isn't going to generally tell you, it is not something 
he will pick up unless you pointed it out to him. Then he will give 
you his legal advise and in my strong opinion, you don't tamper with a 
security protocol which is what being suggested here.

Don't let me stop you from the wiki work.  It is just how I work.

Thanks

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 15 Apr 2014 21:15:15 +0000

> From: ietf [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Tuesday, April 15, 2014 4:57 PM
> To: Alessandro Vesely
> Cc: [email-masked]

Many protocols do not address sudden individual implementer changes to their implementation. I do believe that there were various issues involving DNSSEC trust chains when upstream participants (including CC TLDs) implemented "sudden" changes. Are you expecting something like "MUST provide x days notice of intended change" to make it non-sudden or require a rollback if more than x mailing lists have problems? Are there any other IETF standards that would be a reference point for such a provision? I'm not trying to be cute or argumentative - I'm just not familiar with something like this in any standards I can think of.

> The whole point of Yahoo moving to a restrictive policy is to force a cleanup
> of their domain usage, to increase its security quality, even if it hurts the
> innocent users who were using their domains in public mail list areas.
> 
> So I would personally refrain from any product liability risk that its ok to
> "tamper" with their DKIM secured author domain submissions.
> 
> Case in point, lets say a real bad message got into the list, unsigned,
> purported from Yahoo, the 5322.From was rewritten and distributed to other
> list users and some of those users were "harmed"
> at legal fault here?  Not YAHOO. They are legally protected.  The MLM, who
> wistfully and intentionally ignored policy and even went as far to break the
> security, is now at risk.
> 
> No, its not silly, and just because I am not a lawyer, doesn't mean we don't
> think about these things in our product development.  In fact, it is generally
> the engineer, us, that has to ask the our lawyers if this is ok.  He isn't going to
> generally tell you, it is not something he will pick up unless you pointed it out
> to him. Then he will give you his legal advise and in my strong opinion, you
> don't tamper with a security protocol which is what being suggested here.
>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 15 Apr 2014 17:20:03 -0500

On 4/14/14 9:23 AM, Dave Crocker wrote:

> different rfc5322.From field, including one that looks like some sort 
> of 'rewrite' of the one used by the original author.

It's legitimate for a mailing list to rewrite the author, but it would 
be wrong. :-)

More seriously: If the mailing list wishes to express that I am the 
author of *this message*, then I belong in the "From:" field. That 
differs semantically from forwarding a message authored by me; then the 
list is saying that the list is the author, and it is simply quoting me, 
but that the list is the entity that should be considered to have 
written the message. For most mailing lists, that seems like the wrong 
semantics to try to convey.

There should be a mechanism for an author to send a message to a mailing 
list, granting the mailing list permission to redistribute that message, 
and have that permission conveyed to the mailing list recipient such 
that when the mailing list recipient receives the message, they can 
assure themselves that the originating domain is OK with that 
redistribution. Sounds like some protocol which could be written.

(If the originating domain is expressly *not* OK with the 
redistribution, the mailing list should bounce the message back to the 
author saying as much.)

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 Apr 2014 18:57:55 -0400

On 4/15/2014 6:20 PM, Pete Resnick wrote:
>> different rfc5322.From field, including one that looks like some
>> sort of 'rewrite' of the one used by the original author.
>

+1.

> differs semantically from forwarding a message authored by me; then
> the list is saying that the list is the author, and it is simply
> quoting me, but that the list is the entity that should be considered
> to have written the message. For most mailing lists, that seems like
> the wrong semantics to try to convey.
>
> There should be a mechanism for an author to send a message to a
> mailing list, granting the mailing list permission to redistribute
> that message, and have that permission conveyed to the mailing list
> recipient such that when the mailing list recipient receives the
> message, they can assure themselves that the originating domain is OK
> with that redistribution. Sounds like some protocol which could be
> written.

The methods was developed.  It was discussed during SSP, proposed in 
2006 DSAP I-D [1] as an Authorized, or Allowed Signer List (ASL),  and 
Murray wrote 2012 ATPS [2] to piggy back off the ADSP as an extension.

I've implemented ADSP, ATPS in our Mailing List Server (MLS).  A 
wizard was created [3] for public usages. A private version used for 
customers for their DKIM manager. I've held back on DMARC support but 
it will be the exact logic add.

> redistribution, the mailing list should bounce the message back to the

I would suggest it be more of an ACCEPT + NOTIFY with explanation 
rather than bounce, but yet, the denial is needed.  Its also described 
in DSAP and I believed also in Murray's DKIM Mailing List BCP [4].

-- 
HLS

[1] DKIM Signature Authorization Protocol
     http://tools.ietf.org/html/draft-santos-dkim-dsap-00

[2] DKIM Authorized Third-Party Signatures
     http://tools.ietf.org/html/rfc6541

[3] DKIM Policy Zone Record Generator and Test Simulator v2.7
     http://www.winserver.com/public/wcadsp

[4] DKIM and Mailing Lists
     http://tools.ietf.org/html/bcp167

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2014 11:00:31 +1200

Pete,

On 16/04/2014 10:20, Pete Resnick wrote:
...

> redistribution, the mailing list should bounce the message back to the

Isn't that exactly what p=reject implies? If so, the logical behaviour
for all list software would be to check the DMARC record for the
originating domain of each message, and bounce it if p=reject.

   Brian

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 15 Apr 2014 19:14:37 -0400

> But the problem is YAHOO doesn't want you to do this (rewrite).

That's OK, we didn't want Yahoo turning on DMARC p=reject.  Life's
tough sometimes.

> list users and some of those users were "harmed" in some fashion that it
> worth the effort to sue.   Guess who would be at legal fault here?  Not
> YAHOO. They are legally protected.  The MLM, who wistfully and intentionally
> ignored policy and even went as far to break the security, is now at risk.

The message was unsigned before it hit the mailing list, and it's
unsigned after the mailing list altered the from field.  So the
mailing list software did nothing to "break" security in that case.
Furthermore, the from field would be "[email-masked]".  So
obviously there is nothing that can be said about whether the message
came from a yahoo user or not.

Cheers,

							- Ted

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 16 Apr 2014 00:14:47 +0100

On 15 Apr 2014, at 23:20, Pete Resnick <[email-masked]> wrote:
>> Mediators, like mailing lists, take final delivery and post a new message.  In formal terms, it's legitimate for them to create a different rfc5322.From field, including one that looks like some sort of 'rewrite' of the one used by the original author.
> 
> It's legitimate for a mailing list to rewrite the author, but it would be wrong. :-)
> 
> More seriously: If the mailing list wishes to express that I am the author of *this message*, then I belong in the "From:" field. That differs semantically from forwarding a message authored by me; then the list is saying that the list is the author, and it is simply quoting me, but that the list is the entity that should be considered to have written the message. For most mailing lists, that seems like the wrong semantics to try to convey.
> 
> There should be a mechanism for an author to send a message to a mailing list, granting the mailing list permission to redistribute that message, and have that permission conveyed to the mailing list recipient such that when the mailing list recipient receives the message, they can assure themselves that the originating domain is OK with that redistribution. Sounds like some protocol which could be written.
> 
> (If the originating domain is expressly *not* OK with the redistribution, the mailing list should bounce the message back to the author saying as much.)

That suffers the same problems as X-O-A-R: you have to know when to trust the intermediate.  In the absence of that knowledge, any message transformation is invisible to the recipient, and potentially malicious.  You would have to invent a scheme for identifying transformations, so users could verify them against the original sender's signature.

DMARC has put *ALL* the trust into the From: field.  That is very unfortunate, but it seems to be the DMARC peoples' idea of a foolproof, user-visible identifier.

Cheers,
Sabahattin

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Apr 2014 19:15:15 -0400

On April 15, 2014 12:25:40 PM EDT, Dave Crocker <[email-masked]> wrote:
>IETF to
Considering we're just in the finishing stages of spfbis, which you participated in significantly, and none of those fears were realized despite a charter that permitted incompatible changes if really needed I have a hard time understanding how you would believe all that to be true. 

I think we entirely agree on the facts.  I fully concur you have been loud and vigorous.

I also think it's not at all surprising given the volume and vigor coming from the DMARC developers that not that many people jumped up and lept into the fray.

Scott K

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 15 Apr 2014 19:17:20 -0400

> originating domain of each message, and bounce it if p=reject.

The question is which is more or less unfriendly? 

1)  Forbidding yahoo.com users from participating on mailing lists

2)  Rewriting the from field of yahoo.com users.

I could easily see the mailing list software making this be
configurable, so it's up to each mailing list admin.  :-)

	      	      	    	 	      	      - Ted

P.S.  #1 could also be combined with a nice message inviting the
yahoo.com user to find another e-mail provider.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 15 Apr 2014 15:36:20 -0700

Hi Mike,
At 13:30 15-04-2014, MH Michael Hammer (5304) wrote:
>My experience with regard to working groups is that it is 
>(technically) easy to participate and does not necessarily involve 
>any particular costs. I don't go to IETF meetings but have 
>participated in WG sessions during IETF meetings through jabber. Not 
>the optimal solution but it works. I think that the notion of 8000lb 
>gorillas somewhat misrepresents the situation. Some of the active 
>participants in the working groups I've been involved with continue 
>their involvement even when they change employers. With that in 
>mind, I believe that in many cases it truly is the individual and 
>not the individual as mouthpiece for the organization. I also 
>believe that the 8000lb gorillas have many of the same interests as 
>smaller organizations and individuals even though there are times 
>where interests may diverge. It's also clear to me that there is not 
>uniformity of interests across constituencies within large 
>organizations. It's complex. So let's talk.

It is, as you mentioned, complex.  I'll be one-sided in this 
comment.  There is a cost to participation on the mailing lists and 
to attend meetings.  There is a higher burden for a small company or 
an individual.  People from small companies sometimes get ignored or 
it is like the minority view (see Dave Cridland's message at 
http://www.ietf.org/mail-archive/web/ietf/current/msg87389.html ).

I can understand that an individual is not the mouthpiece of the 
organization if that individual sometimes speaks up to say that 
management is saying X but he or she does not think that it is a 
great idea.  You have tried to be positive by discussing about this 
publicly, politely and without resorting to marketing 
language.  Let's see who else would like to talk.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 16 Apr 2014 01:38:09 -0000

>originating domain of each message, and bounce it if p=reject.

That's certainly been mentioned a lot of times and is certainly consistent
with what p=reject says it means.

The problem is pragmatic: there are a lot of people who use Yahoo's
mail, very few of them understand the technology very well, and they'd
see this as just another baffling thing that happens on their
computers.  I would like to encourage all of the Yahoo users on my
lists to find a better provider, but that will take years.  In the
meantime, the church has a lot of meetings to organize.  It's a market
power problem, not a technical problem.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 15 Apr 2014 22:18:26 -0400

Murray asked a couple of interesting questions, which I will address 
separately in separate message threads.

To the question why are mailing lists special, they're somewhat special, 
but they're more interesting here as canaries in the coal mine.

As a rough estimate, roughly 90% of e-mail is spam, most of what's left is 
bulk broadcast mail, most of what's left after that is transactional 
sort-of-broadcast mail, and the little bit at the end is discussion lists, 
individual mail, and some miscellaneous other stuff.  Nonetheless, people 
have consistently said that they want to get their individual mail, and 
don't care about the broadcast mail.  I'm not aware of surveys where they 
ask specifically about discussion lists, but since each message is 
generally hand written by an identifiable person, I'd expect people to 
consider it a lot closer to individual mail than the daily blast from 
BigCo.

So mailing list mail is special for the same reason individual mail is 
special--it's the mail people want.

The reason it's not special is that it's just the most visible example of 
a wide variety of legitimate useful mail that DMARC can't describe, and 
that are broken by DMARC policies other than p=none.

For example, I send and receive my Yahoo mail on my Gmail account, and 
have done so for years.  Gmail makes the obvious checks to ensure that 
it's my account, so it's just as secure as sending from Yahoo, and it's 
useful.  Or it was useful until last weekend. Now a lot of it bounces.

Or there's the WSJ's mail an article feature.  It's useful, nobody abuses 
it.  Yahoo users can't use it any more.

There's lots of these, and the only thing "wrong" with them is that DMARC 
can't distinguish them from other somewhat similar mail sources that send 
spam.  The proposals I'm seeing from the DMARC cartel are basically Google 
Purge applied to e-mail:

http://www.theonion.com/articles/google-announces-plan-to-destroy-all-information-i,1783/

Surely we can do better than that, but that's the next message.

Regards,

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 16 Apr 2014 03:44:45 +0000

> From: S Moonesamy [mailto:[email-masked]]
> Sent: Tuesday, April 15, 2014 6:36 PM
> To: MH Michael Hammer (5304); [email-masked]
> Subject: Let's talk (was: DMARC: perspectives from a listadmin of large open-
> source lists)
> 
> Hi Mike,
> >(technically) easy to participate and does not necessarily involve any
> >particular costs. I don't go to IETF meetings but have participated in
> >WG sessions during IETF meetings through jabber. Not the optimal
> >solution but it works. I think that the notion of 8000lb gorillas
> >somewhat misrepresents the situation. Some of the active participants
> >in the working groups I've been involved with continue their
> >involvement even when they change employers. With that in mind, I
> >believe that in many cases it truly is the individual and not the
> >individual as mouthpiece for the organization. I also believe that the
> >8000lb gorillas have many of the same interests as smaller
> >organizations and individuals even though there are times where
> >interests may diverge. It's also clear to me that there is not
> It is, as you mentioned, complex.  I'll be one-sided in this comment.  There is
> a cost to participation on the mailing lists and to attend meetings.  There is a
> higher burden for a small company or an individual.  People from small
> companies sometimes get ignored or it is like the minority view (see Dave
> Cridland's message at http://www.ietf.org/mail-
> archive/web/ietf/current/msg87389.html ).
> 

I think this conflates two different issues:

1) Cost to participation. While I may work for a larger organization, much if not most of my participation is in addition to my other work obligations. I know of other folks in a similar situation. I participated before I worked at a large organization, I participated when I had my own small business and I may choose to participate in the future if my circumstances change. There are other people whose occupation consists solely of standards work. I don't have any meaningful answer to your comment. Quite frankly, I'm asking myself why I should personally continue to engage with the IETF process at all. It's not as if my employer is demanding it. Do I really want to be engaging with IETF after a 16 hour day working on other stuff? It must be masochism.

2) Getting ignored or minority view. I don't believe it is simply a function of company size - at least for the WGs I've participated in. I'd assert that at least in the email/email auth WGs it's more a function of long term participants, many of whom have calcified positions (across the spectrum). I can think of at least one person from a relatively large company who gets ignored a fair bit, so size is not necessarily a factor. I've been in the minority view on various issues in the WGs I've participated in. That's life - I chose Betamax. To a certain extent it's also a function of who is wrangling the WG and how they manage the WG. I don't really think about whether a person is with a large company, a small company or an individual - I'm more interested in the quality and practicality of their ideas. I'm more of a security and operations guy and that colors my perspective.

I'm not sure if you are looking for a response to Dave Cridland's message in the context of DMARC specifically. As I noted when I first posted to this group, I don't speak on behalf of DMARC and my comments are on a personal basis. When DMARC came along, as a sender I only had to publish a p=reject policy. We (my employer) had done the heavy lifting in terms of changing our mailing practices back in 2007 before there was a dmarc.org or a spec. I had some concerns about a wide open WG but wasn't necessarily against it. My concerns were more along the line of how much of a grind it might be on a personal basis (after my experiences with other WGs). I do recognize that others made a significant investment in implementing running code to make things work. I think a lot of people underestimate what was involved and overly discount concerns about radical modifications to the spec. When I did my original effort in 2007 it was a five month project involving quite a few people to change how our websites handled mail to accommodate strong authentication for SPF and DKIM. I'll also point out that the interoperability event for DKIM didn't take place until 2008 which meant I was somewhat going out on a limb. I'm sure that for others to do their DMARC implementations on the mailbox provider side several years later it was a larger effort than what I went through. My personal belief is that nobody was looking to get an IETF rubber stamp. Perhaps the concerns might have been communicated differently and perhaps there might have been a little less skepticism as to intent.

So on to the mail list issue. On one level I want to say not my issue. I don't publish p=reject for any domains with users that send to mail lists so as I've said, my ox isn't getting gored. There were plenty of discussions in the DKIM working group about 1st party signatures vs 3rd party signatures and trust and reputation and who should do what and who wouldn't do what. At the end of the day the can was kicked down the road. So here we are. I don't have any answers for this group. I've already stated in a previous post how I think it will play out. I'm leaning towards just walking away and spending cycles on something as that is more productive from my perspective. The juice just isn't worth the squeeze.

> I can understand that an individual is not the mouthpiece of the organization
> if that individual sometimes speaks up to say that management is saying X
> but he or she does not think that it is a great idea.  You have tried to be
> positive by discussing about this publicly, politely and without resorting to
> marketing language.  Let's see who else would like to talk.
> 

I don't think you are likely to see someone speaking up in that particular way. "My boss has bad ideas" posted to a public forum is not a career enhancing move even if phrased politely. Those sorts of issues would likely get resolved internally or the person would likely choose to move to another roost if it is a significant issue. That's just common sense. At least for me, in the WGs I've participated in, I've had a lot of latitude because the issues are technical and it is more me keeping management apprised of what is happening and what I'm doing than me getting directives. I can't speak for others or other organizations. I don't have anything to sell or market so I have no reason to use marketing language. My goal is to protect end users from maliciousness that tries to leverage our domains and brands - things like SPF, DKIM and DMARC help do that in conjunction with other efforts such as takedowns, blocking, prosecutions, etc. I also get involved in other anti-abuse efforts that have nothing to do with my employer - because I believe it is the right thing to do. Standards are just one piece of the puzzle.

It's been a long day and I've rambled on more than enough.

Mike

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 16 Apr 2014 00:20:08 -0400

> DMARC has put *ALL* the trust into the From: field.  That is very unfortunate, but it seems to be the DMARC peoples' idea of a foolproof, user-visible identifier.

First off, with xoar, you don't have to trust the intermediary.  If one 
removes DMARC's alignment mechanism - you can validate that a message 
originated from a yahoo address by dint of the crypto signature - as 
long as you don't modify any of the fields that get signed.  Now if you 
want to allow modification of the subject field (e.g., adding a tag) 
and/or the body (e.g., adding header and footer) - then you might have 
to be a little cleverer, perhaps by providing information about the 
diffs in extra headers and doing a few comparisons at the receiving end 
(subject tag = *****<original-signed-subject>).

It's worth noting that way back in 1999, the folks who designed HTTP 1.1 
designed an authentication scheme that works through proxies. They took 
the time to actually acknowledge mechanisms that were in use (i.e., 
caching proxies) and design mechanisms that could work in concert with 
them (and yes, in some cases the proxies have to do new things).  Those 
involved in DMARC, seemingly, did not take the same care to respect the 
infrastructure.

Miles Fidelman

---

From: Pete Resnick <[email-masked]>
Date: Wed, 16 Apr 2014 06:34:25 -0500

> That suffers the same problems as X-O-A-R: you have to know when to trust the intermediate.  In the absence of that knowledge, any message transformation is invisible to the recipient, and potentia…

Not necessarily. If the originator of the message sends to a mailing 
list, the originator's site should trust the mailing list to 
redistribute the message and make any transformations. (If you can't 
trust your users to make a decision on which lists to send to, that's a 
different thing.) If the originator's site is going to allow that, you 
could create a mechanism where the originator's site gets some sort of 
cryptographic data from the mailing list site and include that in its 
signed message, such that when the eventual recipient gets the message, 
it can verify that it came from a mailing list site that the originator 
explicitly sent the mail to. That doesn't require the originator's or 
the recipient's site to independently trust the mailing list. (It would, 
of course, be perfectly OK for the recipient's site to check that it's 
getting the list mail from an authorized site; that's separate from of 
the above.)

And again, this is only if the originator indicates that it *wants* to 
allow its users to have their mail redistributed. The site is well 
within rights to indicate that it doesn't want that to happen, and a 
friendly mailing list would bounce the mail in that case.

>> originating domain of each message, and bounce it if p=reject.

Yep.

> 2)  Rewriting the from field of yahoo.com users.

More or less friendly to whom? If yahoo.com says that it doesn't want 
mail from its users sent via other servers, it might be unfriendly to 
its users to bounce the mail, but it's pretty darn friendly to 
yahoo.com. (Imagine the question: "So, you say you don't want things 
with your users' addresses sent from my server. Are you OK with me 
rewriting your users' addresses with '.invalid' on the end and then 
sending them?") And it's much friendlier to eventual recipients of this 
mail to bounce it (forcing the originator to send from a different 
address) than to get a piece of mail that will cause them to get a 
bounce if they reply to it without noticing that there's a ".invalid" at 
the end.

The problem is that the current protocol is not rich enough to express 
everyone's intentions. Yahoo conceivably might want to say, "It's OK to 
receive mail from a yahoo.com user from a site that is redistributing a 
piece of mail that a yahoo.com user explicitly sent to it." But there's 
no way to say that in the protocol now. Given that, yahoo.com has made 
the current choice to say, "Reject all yahoo.com mail that comes from a 
site other than yahoo.com". That's a choice yahoo.com is free to make. A 
friendly mailing list is well within spec to honor that request by not 
redistributing the mail.

> configurable, so it's up to each mailing list admin.  :-)

I think that's a perfectly reasonable thing to do.

pr

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Apr 2014 08:58:16 -0400

It's clear to me that we need at least a non-WG mailing list for this
*technical* discussion.  Fixing the mailing list problem may require
fundamental changes in how things work; and I think that is okay.
Maybe we could try this NNTP thinkg I've heard about :-)

Pete Resnick <[email-masked]> wrote:
    > a decision on which lists to send to, that's a different thing.) If the
    > originator's site is going to allow that, you could create a mechanism
    > where
    > the originator's site gets some sort of cryptographic data from the
    > mailing list site and include that in its signed message, such that
    > when the eventual

so, what you are saying is that based upon the (SMTP) To: address, the sender
needs a signal that this is a mailing list, and some way to react.
Maybe this could be combined with various SMTP DANE mechanisms, or at least,
maybe "Additional RR" could return that kind of information.

I think that there are a whole bunch of architectually important things
here.  The signal has to come early enough to either modify the DKIM process,
or if the signal comes rather late (such as during SMTP delivery), then it
needs to be possible to redo the DKIM process.  I think that this will be
challenging for many large installations where there are multiple layers of
outgoing SMTP delivery machines, and DKIM is just a stage in the process.

But, I don't think it is impossible.
Consider all the other meta info that could be stored along with the "I am a
list" signal... things like how to subscribe, unsubscribe, location of
archive, etc.

Imagine if that signal also changed the protocol from SMTP to NNRP POST?

    > within rights to ndicate that it doesn't want that to happen, and a

Running code.  we need someone to fund and participate in an experiment.
 (cf: other thread about not participating in SDOs anymore)

---

From: "John Levine" <[email-masked]>
Date: 16 Apr 2014 14:08:56 -0000

>..., you 
>explicitly sent the mail to.

The Sympa list manager implemented that in what appears to be a fully
RFC compliant way about a decade ago:

http://www.sympa.org/manual/x509

I don't get the impression it's very widely used.

Every discussion list security proposal I've ever seen includes
building a whitelist of trustworthy mailers, to avoid being spoofed by
bad guys that look like discussion lists but aren't.  Once you've done
that, I've never understood the threat model of anything more complex
than delivering the mail from the whitelisted sources, perhaps after a
cursory check to ensure that it looks like the mail you were
expecting.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Wed, 16 Apr 2014 10:26:15 -0700

Hi Mike,
>I think this conflates two different issues:

Ok.

>1) Cost to participation. While I may work for a larger 
>organization, much if not most of my participation is in addition to 
>my other work obligations. I know of other folks in a similar 
>situation. I participated before I worked at a large organization, I 
>participated when I had my own small business and I may choose to 
>participate in the future if my circumstances change. There are 
>other people whose occupation consists solely of standards work. I 
>don't have any meaningful answer to your comment. Quite frankly, I'm 
>asking myself why I should personally continue to engage with the 
>IETF process at all. It's not as if my employer is demanding it. Do 
>I really want to be engaging with IETF after a 16 hour day working 
>on other stuff? It must be masochism.

One of the reasons to participate in the IETF is self-interest.  The 
IETF standard for IETF participants is attending three out of five 
meetings.  A small business cannot afford that cost.  The list of 
volunteers is at https://datatracker.ietf.org/nomcom/ann/58250/  How 
many of the people are from small businesses?

>2) Getting ignored or minority view. I don't believe it is simply a 
>function of company size - at least for the WGs I've participated 
>in. I'd assert that at least in the email/email auth WGs it's more a 
>function of long term participants, many of whom have calcified 
>positions (across the spectrum). I can think of at least one person 
>from a relatively large company who gets ignored a fair bit, so size 
>is not necessarily a factor. I've been in the minority view on 
>various issues in the WGs I've participated in. That's life - I 
>chose Betamax. To a certain extent it's also a function of who is 
>wrangling the WG and how they manage the WG. I don't really think 
>about whether a person is with a large company, a small company or 
>an individual - I'm more interested in the quality and practicality 
>of their ideas. I'm more of a security and operations guy and that 
>colors my perspective.

The usual explanation for the ways things are is "That's 
life".  That's what gets you (used in a general sense) calcified 
positions, specifications that takes years to be published and other 
IETF problems.

>I'm not sure if you are looking for a response to Dave Cridland's 
>message in the context of DMARC specifically. As I noted when I 
>first posted to this group, I don't speak on behalf of DMARC and my

I wasn't looking for a response as I have been staying out of DMARC 
discussions.

>  comments are on a personal basis. When DMARC came along, as a 
> sender I only had to publish a p=reject policy. We (my employer) 
> had done the heavy lifting in terms of changing our mailing 
> practices back in 2007 before there was a dmarc.org or a spec. I 
> had some concerns about a wide open WG but wasn't necessarily 
> against it. My concerns were more along the line of how much of a 
> grind it might be on a personal basis (after my experiences with 
> other WGs). I do recognize that others made a significant 
> investment in implementing running code to make things work. I 
> think a lot of people underestimate what was involved and overly 
> discount concerns about radical modifications to the spec. When I 
> did my original effort in 2007 it was a five month project 
> involving quite a few people to change how our websites handled 
> mail to accommodate strong authentication for SPF and DKIM. I'll 
> also point out that the interoperability event for DKIM didn't take 
> place until 2008 which meant I was somewhat going out on a limb. 
> I'm sure that for others to do their DMARC implementations on the 
> mailbox provider side several years later it was a larger effort 
> than what I went through. My personal belief is that nobody was 
> looking to get an IETF rubber stamp. Perhaps the concerns might 
> have been communicated differently and perhaps there might have 
> been a little less skepticism as to intent.

Rewriting a specification from scratch is rather silly if there isn't 
a good reason to do that.  In my opinion the purpose of a working 
group is to review the drafts and send work of acceptable quality to 
the Area Director.  It is possible to take into consideration the 
constraints of the various parties if there is a public 
explanation.  At the same time the parties could consider that 
hinting for an IETF rubber stamp is going to be problematic.

I'll highlight a comment from Stephen J. Turnbull:

   "It might help if you gave us the annotated version of what you do like
    about it, instead of telling us that everything we've been doing for
    20 years is wrong, and that we're crazy to object to the violation of
    the most fundamental and ancient email RFC (not to mention violating
    copyright law in every Berne Convention signatory) by corrupting the
    authorship information of each post we process."

If it is difficult to explain in English words, show the source 
code.  It is worthwhile to look into the interoperability issues.  It 
may not be possible to solve all of them quickly.  That's not a 
significant problem as long as a working group does not break too much stuff.

>So on to the mail list issue. On one level I want to say not my 
>issue. I don't publish p=reject for any domains with users that send 
>to mail lists so as I've said, my ox isn't getting gored. There were 
>plenty of discussions in the DKIM working group about 1st party 
>signatures vs 3rd party signatures and trust and reputation and who 
>should do what and who wouldn't do what. At the end of the day the 
>can was kicked down the road. So here we are. I don't have any 
>answers for this group. I've already stated in a previous post how I 
>think it will play out. I'm leaning towards just walking away and 
>spending cycles on something as that is more productive from my 
>perspective. The juice just isn't worth the squeeze.

It's okay to say "not my issue".  It is an issue if most people in 
the group say "not my issue".  If there isn't any progress on the 
issue the note to the Area Director could be "the working group does 
not have the competence to address this issue".

>I don't think you are likely to see someone speaking up in that 
>particular way. "My boss has bad ideas" posted to a public forum is 
>not a career enhancing move even if phrased politely. Those sorts of 
>issues would likely get resolved internally or the person would 
>likely choose to move to another roost if it is a significant issue. 
>That's just common sense. At least for me, in the WGs I've 
>participated in, I've had a lot of latitude because the issues are 
>technical and it is more me keeping management apprised of what is 
>happening and what I'm doing than me getting directives. I can't 
>speak for others or other organizations. I don't have anything to 
>sell or market so I have no reason to use marketing language. My 
>goal is to protect end users from maliciousness that tries to 
>leverage our domains and brands - things like SPF, DKIM and DMARC 
>help do that in conjunction with other efforts such as takedowns, 
>blocking, prosecutions, etc. I also get involved in other anti-abuse 
>efforts that have nothing to do with my employer - because I believe 
>it is the right thing to do. Standards are just one piece of the puzzle.

Speaking about career enhancing moves, common sense dictates that it 
is to be assumed that the individual is the mouthpiece of the 
organization (I am not inferring that you are).  In my opinion 
reviews from individuals affiliated with the companies listed on the 
web page might not fit within the objectivity guidelines.  It may be 
difficult to find an external reviewer if Dave Cridland does not wish 
to donate his intellectual property rights.

Takedowns, blocking, prosecutions, brand protection, etc. are 
non-technical issues.  These issues could be discussed if it helps 
the average participant to understand the puzzle.  Past DKIM and SPF 
discussions could be listed under "gives the WG Chair(s) a headache".

Is this work doable?  I don't know.  Would I put effort to solve 
Company X is breaking the internet?  No, as it is an expense which I 
cannot afford.  Did I learn anything from the discussions on the 
previous topic?  Yes. :-)

Regards,
S. Moonesamy

---

From: Dave Cridland <[email-masked]>
Date: Wed, 16 Apr 2014 19:23:51 +0100

On 16 April 2014 18:26, S Moonesamy <[email-masked]> wrote:

> Speaking about career enhancing moves, common sense dictates that it is to
> be assumed that the individual is the mouthpiece of the organization (I am
> not inferring that you are).  In my opinion reviews from individuals
> affiliated with the companies listed on the web page might not fit within
> the objectivity guidelines.  It may be difficult to find an external
> reviewer if Dave Cridland does not wish to donate his intellectual property
> rights.
>

I'm actually quite happy donating IPR; I do it all the time. The XSF policy
on copyright is an assignment one, for example.

I have no idea what the IPR policy is for DMARC, it has been developed
outside the IETF process, and changes to it from the IETF are not welcome.

So from my perspective, it's like saying "Hey, we'd like you to spend time
and effort on reviewing this so we can tell you why we're not going to make
any changes".

Dave.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Apr 2014 11:41:20 -0700

> that are broken by DMARC policies other than p=none.

As I see it, this is probably the core of the stalemate.  I agree that
DMARC, and its various antecedents that we all know and love, can't
precisely describe mailing list traffic as it's currently defined.  What I
observe, though, is that there's typically lots of talk about what we can't
do to add that capability, and almost none about what's actually possible.
People get discouraged and give up.  This isn't a path to success.

I'm all for being as incremental and non-destructive as possible when
building these things.  I also don't think it's possible to be completely
invisible 100% of the time.

Sure, whitelisting is one possible solution.  Publishing a whitelist is
easy, but populating it, managing it, making it robust, making it fair, and
protecting it against fraudulent entries needs to be sorted out, whether
it's a public whitelist or a private one.  Are we certain, though, that
it's flatly impossible to adjust lists in such a way that their traffic
could be described by these mechanisms?

-MSK

---

From: Dave Cridland <[email-masked]>
Date: Wed, 16 Apr 2014 21:01:04 +0100

On 16 April 2014 19:41, Murray S. Kucherawy <[email-masked]> wrote:

> whitelist or a private one.  Are we certain, though, that it's flatly
> impossible to adjust lists in such a way that their traffic could be
> described by these mechanisms?
>
>
If you mean, can we change mailing lists such that they're describable by
DMARC without any change in behaviour, whilst maintaining the essential
premises of mailing lists, then I don't see a mechanism that would allow
this.

If you mean, can we change DMARC (such that existing deployments will have
to change) such that a modified mailing list model (that handles the
existing use cases of mailing lists) would be describable, then I think
that's entirely possible.

Unfortunately, the only option I thought was possibly available isn't
permissible by the specification - therefore, the only solution involves
alterations to the deployed base, which has been ruled impossible for over
a year now.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 16 Apr 2014 21:38:26 +0100

> alterations to the deployed base, which has been ruled impossible for over
Oh, I tell a lie, it's just not where I expected, and not quite as nice as
I'd hoped.

So I think what needs to happen is that a new policy of "sender-reject" or
something is allowed, which is essentially deferring to the sender, so
receivers would check:

1) The sender exists and is valid.

2) The mail has a valid DKIM signature from the sender and otherwise
complies with the published DMARC policy.

3) Any such policy is treated as p=reject

That is, if I have a mailing list at "[email-masked]", and a
p=forward-or-reject then my recipients would check for a _dmarc.ietf.org as
well, but ignore any p=, and treat as p=reject.

This means that mailing lists (and other forwarding cases) are enforced
into having DMARC records in order to forward DMARC originating messages,
which seems reasonable, and the Sender addresses must also be relatively
sensible, which they normally are already.

In fact, this case handles even people using gmail.com with their Yahoo
address sending messages to mailing lists, I think.

Note that the problem is that existing DMARC deployments which don't know
about sender-reject will either treat is as p=none - if there's a rua
listed - or "take no action", and I've not looked into this enough to
decide what that means.

So for Yahoo, should they implement this change, would effectively take a
backwards step to p=none until the DMARC deployments caught up, which would
be a little confusing to mailing list operators, but at least safe.

The alternative would be to add a new tag indicating this kind of deferral
to the sender; unknown tags are ignored, so this would behave like a reject
until software was updated. The problem with that is that it'd be very
unpredictable whether messages would pass or not; for mailing lists, which
typically drop subscribers after a certain number of failed deliveries, I
think it'd remain a huge problem.

In either case, there would be a knock-on to UAs, which would need to show
in the UI that the message had been forwarded - gmail does this with it's
"via", for example, so I don't think this is onerous.

I may be missing something.

Dave.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 16 Apr 2014 20:44:37 +0000

From: Dave Cridland [mailto:[email-masked]]
Sent: Wednesday, April 16, 2014 2:24 PM
To: S Moonesamy
Cc: MH Michael Hammer (5304); [email-masked] Discussion
Subject: Re: Let's talk (was: DMARC: perspectives from a listadmin of large open-source lists)

On 16 April 2014 18:26, S Moonesamy <[email-masked]<mailto:[email-masked]>> wrote:
Speaking about career enhancing moves, common sense dictates that it is to be assumed that the individual is the mouthpiece of the organization (I am not inferring that you are).  In my opinion reviews from individuals affiliated with the companies listed on the web page might not fit within the objectivity guidelines.  It may be difficult to find an external reviewer if Dave Cridland does not wish to donate his intellectual property rights.

MH: Reviews from 3rd parties have been always welcome and were specifically asked for from a number of people unaffiliated with dmarc.org. There were external reviews (although it would have been nice to see more) from various people. I note that Jim Fenton just posted to the dmarc-ietf list about many of his suggestions being incorporated.

With regard to mouthpieces, there are some people who clearly are and other people who are not. It’s generally not too difficult to figure out the difference between the two.

I'm actually quite happy donating IPR; I do it all the time. The XSF policy on copyright is an assignment one, for example.

I have no idea what the IPR policy is for DMARC, it has been developed outside the IETF process, and changes to it from the IETF are not welcome.

MH: The IPR policy for DMARC falls under the OWF – All of the participating organizations have signed agreements for this. Anyone can contribute as an individual but the participating organizations have specific contractual obligations. There are more details on the OWF basis for anyone interested in participating or contributing through the dmarc-discuss list at http://www.dmarc.org/note_well.html.  Considering that there were multiple attempts to hand the DMARC spec over to the IETF I think the last part of your statement is a stretch. There were constraints/considerations that I think could have been worked out, but for now that is water under the bridge.

Speaking only for myself because I’m not any ones mouthpiece, I believe that any contributions which improve the technical rigor of the specification are valued and are of benefit to the community in the larger sense. If I believed otherwise I would not be participating.

So from my perspective, it's like saying "Hey, we'd like you to spend time and effort on reviewing this so we can tell you why we're not going to make any changes".

MH: I respect your perspective Dave. I can only point to the experience of others that have taken the time and effort and found their suggestions incorporated. Because the participating organizations are bound by OWF and the participation agreement, there is an obligation to follow certain processes. I will say that from my perspective it was never anticipated that we would be going this long without a handoff to IETF. I’m not looking to debate whether it should or shouldn’t be or how it might be at this point, I’m only trying to provide some perspective into why the DMARC process is currently the way it is.

Remember (understand?) that this (DMARC) started because various participants had private bilateral agreements regarding policy assertions and reporting. When I first started working on my implementation (and operational changes) I had to ask various mailbox providers to provide feedback on our mail and authentication failures, etc. I was accommodated to various degrees because I/my organization was perceived as aggressively moving to combat abuse. Most of the providers that responded had to make a special effort to provide that sort of information and the format and what was included varied from provider to provider. It was also easier for some because we had partnership or other contractual agreements already in place that addressed privacy concerns. I would get a slice of data from one provider and spend an incredible amount of time trying to get it to mesh with a different slice of data from someone else. Once we implemented (strong assertions) for SPF and DKIM, some of the folks working on validation implementations used our mail streams as a reference case as they developed their validation implementations (and remember, this was pre-DMARC and even before DKIM was finalized). As participants in the bilateral efforts compared notes and experiences it was natural to try and standardize the interactions between all the various players. And once that occurred there was a desire to make it an open standard rather than a private club because there was a belief that it was beneficial to the wider community – thus DMARC. There were other pre-DMARC efforts that did not produce any visible outcome. Some of them I participated in and others I did not because I felt they were unlikely to be successful. So at the end of the day, if your perspective is that it isn’t worth your time and effort,  I can’t think of anything I or anyone else might say that would change your mind.

Mike

---

From: "John R Levine" <[email-masked]>
Date: 16 Apr 2014 16:57:22 -0400

> I may be missing something.

How do I distinguish the nice mailing lists at ietf.org from random evil 
spammer domains sending spam with List-ID headers?

Every proposal I've seen like this ends up tripping over the fact that 
there is no technical way to distinguish between mail from real mailing 
lists and spam that looks like it's from mailing lists.  Hence you need a 
whitelist for the real mail, at which point all of the mechanism beyond 
the key for the whitelist (probably a DKIM signature) is superfluous.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Apr 2014 15:53:46 -0700

On Wed, Apr 16, 2014 at 1:57 PM, John R Levine <[email-masked]> wrote:

> whitelist for the real mail, at which point all of the mechanism beyond the
> key for the whitelist (probably a DKIM signature) is superfluous.
>

Let's assume for the moment that a whitelist is the only option.  (Pete
made a different suggestion that I haven't read fully yet, for example.)
Do you envision each operator maintaining its own whitelist, or one or more
public registries of them, or something else?

It may be the case that it's the only way, but if so, then someone needs to
write down some how-tos on this as well.  May as well begin to develop that
idea.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Apr 2014 15:56:25 -0700

> alterations to the deployed base, which has been ruled impossible for over

Suppose you had the power to crack that barrier and do the impossible.
What would you do?

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 16 Apr 2014 19:16:26 -0400

Murray S. Kucherawy wrote:
> On Wed, Apr 16, 2014 at 1:57 PM, John R Levine <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     How do I distinguish the nice mailing lists at ietf.org
>     <http://ietf.org> from random evil spammer domains sending spam
>     with List-ID headers?
>
>     Every proposal I've seen like this ends up tripping over the fact
>     that there is no technical way to distinguish between mail from
>     real mailing lists and spam that looks like it's from mailing
>     lists.  Hence you need a whitelist for the real mail, at which
>     point all of the mechanism beyond the key for the whitelist
>     (probably a DKIM signature) is superfluous.
>
>
> Let's assume for the moment that a whitelist is the only option.  
> (Pete made a different suggestion that I haven't read fully yet, for 
> example.)  Do you envision each operator maintaining its own 
> whitelist, or one or more public registries of them, or something else?
>
> It may be the case that it's the only way, but if so, then someone 
> needs to write down some how-tos on this as well.  May as well begin 
> to develop that idea.
>
>
Well... yahoo, aol, and others DO keep whitelists now - and various 
mechanisms for getting on them.  Yahoo doesn't, however, seem to apply 
their whitelisting methods to their own mail that's passed through 
DMARC.  Hmmm.....

Miles

---

From: Pete Resnick <[email-masked]>
Date: Wed, 16 Apr 2014 18:25:55 -0500

Replying to two in one. They're sorta related.

On 4/16/14 7:58 AM, Michael Richardson wrote:

> *technical* discussion.

Yeah, we are starting to move into solution space, which needs to be 
discussed in a specific technical forum. I'll try to keep it short.

> maybe "Additional RR" could return that kind of information.

The originator (well, more to the point, the originator's mail server) 
doesn't need a signal that it's a mailing list; it's simply that the 
destination makes an "if I forward the mail, I'll be including this" 
piece of data available, and the originator's server can then include 
that in the signature of the message. I was thinking this could be in 
some special kind of DMARC (or whatever) record that lived in the 
mailing list's domain and could be queried by the originator's server.

>   (cf: other thread about not participating in SDOs anymore)

Bah. I do need to respond in that other thread, but I've become more 
sanguine about standardization after Vidya's article: I agree with a 
good deal of what she says, and I think she's categorized the problem 
correctly. Her having done that, I now see paths forward. More on the 
other thread.

On 4/16/14 3:57 PM, John R Levine wrote:

> How do I distinguish the nice mailing lists at ietf.org from random 
> evil spammer domains sending spam with List-ID headers?
>
> there is no technical way to distinguish between mail from real 
> mailing lists and spam that looks like it's from mailing lists.

At least in the back-of-the-envelope scheme I suggested, the receiver 
doesn't need to distinguish mailing lists: The originator's system finds 
out where the mail is going, gets some information from the destination, 
and signs that and sends it with the message. The mailing list sends 
that along to the recipients. When my (one of the recipient's) server 
looks at that info, it determines that the originator sent the message 
directly to the mailing list, and I can tell that the mailing list sent 
it to me. My server doesn't need to determine whether the mailing list 
is "evil"; it knows that the person with the (e.g.) yahoo.com address 
sent to that mailing list from a yahoo.com server. That's what it cares 
about.

(And again, anyone can choose to continue to say, "No redistributing 
this message". The mailing list, or the eventual recipients if the 
mailing list doesn't play, should bounce the message in that case.)

pr

---

From: [email-masked]
Date: Wed, 16 Apr 2014 23:42:01 +0000

On Wed, Apr 16, 2014 at 07:16:26PM -0400, Miles Fidelman wrote:
> mechanisms for getting on them.  Yahoo doesn't, however, seem to
> apply their whitelisting methods to their own mail that's passed
> through DMARC.  Hmmm.....

All of the major mail providers are almost certainly using some kind
of machine-learning that takes multiple things into account, including
SPF and DKIM results, message body filtering, etc.

The problem is that this only helps people who are receiving mail at
yahoo.com or gmail.com, etc.  The problem that Yahoo seems to be
fixated on, at least with respect to their desire to enable DMARC
p=reject, is that they don't trust that *other* people will have good
enough spam detection schemes such that they can detect messages sent
to other mail destinations (for example, such as [email-masked])
where the recipient claims to be [email-masked].

So the problem is not yahoo maintaining a set of whitelists, it's
everybody *else* needing to have a good enough machine learning
algorithms so they can detect bad e-mail.  If everyone did, then you
wouldn't need any DMARC policy other than p=none.  They could all look
at the SPF and DKIM, the message body, their ML algorithms that have
led them to conclude that [email-masked] is a valid email list, and not
a spammer trying to look like a mailing list, and make the appropriate
ham vs spam determination.

In some sense the DMARC p=reject is basically Yahoo saying, "I don't
trust your spam algorithms, so please use a really bone-headed
algorithm which rejects any message claiming to be from
[email-masked] if the sender and the from field don't match."

Regards,

							- Ted

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 16 Apr 2014 20:38:58 -0400

Michael Richardson wrote:
> P

well there is dmarc-ietf.org :-)

Miles Fidelman

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Apr 2014 13:02:29 +1000

Part of the problem is that DKIM requires that email passes through
the signer's MTA to get the signature added.  Per user certs chained
to the published cert would address this issue.

This would allow someone using gmail to send as @yahoo.com.  Yes,
it requires all the PKI stuff like CRL's for compromised accounts.
You report spam that passes DKIM to @yahoo.com who then revoke the
cert.  The CRL could be a DNS entry with a low negative TTL for
non-existing entries.  Note these CERT's don't need to be tied to
account names.  Yahoo would know who they were issued to but no one
else.  Multiple users could in theory use the same CERT.  Vetted
mailing list could use a CERT after re-writting Subject, attaching
footers etc.  This CERT would be marked as "on behalf of" indicating
that it is not the actual user that is signing the message but a
proxy.

This still requires a mailing list to sign the outgoing email and
have a collection of CERTS to do this with.  Mailing lists without
a CERT would reject incoming messages which would fail DKIM reporting
back to Yahoo why.  This would be a trigger to get a mailing list
CERT.  The yahoo user would need to sign off that they intended to
send to a mailing list before a CERT was issued.  This step could
be automated, but would be a brake on process abuse.

The email would have contain the necessary linkage information in
the headers to get back to the Yahoo's public key.

This isn't a perfect system but it would allow Yahoo to control who
gets to send email as [email-masked].

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 17 Apr 2014 00:03:00 -0400

> destination makes an "if I forward the mail, I'll be including this" piece of 
> data available, and the originator's server can then include that in the 
> signature of the message. I was thinking this could be in some special kind 
> of DMARC (or whatever) record that lived in the mailing list's domain and 
> could be queried by the originator's server.

We argued at great length about this issue when we were doing DKIM.  The 
magic token has to be cryptographically tied to the contents of the 
original message, or bad guys can take the token from a real message and 
replace the body with spam.  So that means a token tied to a hash of the 
contents of the message which is, of course, a DKIM signature.  This 
scheme is equivalent to requiring that lists preserve DKIM signatures, 
which they don't.

Every attempt to create a signing scheme that is flexible enough to deal 
with all the routine stuff that lists do (e.g., reorder, discard, or 
flatten MIME parts while adding the usual subject tags and body footers) 
while being robust enough to prevent bad guys from replacing the message 
with spam has completely failed.  We can try again, but I don't see any 
reason to think that the result would be any different.

Hence you can only accept mutated messages from sources you trust, i.e., a 
whitelist, and once you have a whitelist, you might as well just deliver 
the whitelisted mail.  Maybe I'm missing something here, but we've gone 
around this barn an awful lot of times over the past decade and always 
ended up in the same place.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 17 Apr 2014 00:12:59 -0400

> public registries of them, or something else?

On the assumption that we have reasonably good agreement about what would 
qualify for DMARC whitelisting, I'd think you'd want a small set (maybe 
only one) of public whitelists.

If each receiver has to do its own whitelist, that means that nobody bug a 
big gorilla who can afford to create a whitelist can apply DMARC policies.

R's,
John

---

From: Pete Resnick <[email-masked]>
Date: Wed, 16 Apr 2014 23:53:59 -0500

On 4/16/14 11:03 PM, John R Levine wrote:
>> The originator (well, more to the point, the originator's mail 
>> server) doesn't need a signal that it's a mailing list; it's simply 
>> that the destination makes an "if I forward the mail, I'll be 
>> including this" piece of data available, and the originator's server 
>> can then include that in the signature of the message. I was thinking 
>> this could be in some special kind of DMARC (or whatever) record that 
>> lived in the mailing list's domain and could be queried by the 
>> originator's server.
>
> The magic token has to be cryptographically tied to the contents of 
> the original message

No it doesn't. It has to be cryptographically tied to the mailing list's 
re-sending of the message. How to do that with asymmetric keys should be 
discussed somewhere other than on this list.

pr

---

From: Dave Cridland <[email-masked]>
Date: Thu, 17 Apr 2014 07:35:30 +0100

> key for the whitelist (probably a DKIM signature) is superfluous.
There's no more need for whitelist here than on DMARC mail as things stand,
of course, but it does mean that senders need tracking as well as authors,
and senders need to be explicit and reliable. I'd assume reputation
services (of which whitelists are just an extreme case) would be in play
regardless.

Let's consider the message to which I am replying.

Right now, my MUA treats this as a message "From John R Levine <
[email-masked]>". This means that any policy on the message origination
comes from looking solely at the taugh.com domain. We'll pretend it has a
DMARC policy. Herein lies the Yahoo/DMARC issue, because unless your policy
essentially stipulates that the IETF is allowed to spoof you, we're stuck.

What I'm suggesting is not that, but that my MUA notes that the poloicy of
taugh.com allows different senders, and switches to considering the sender
domain - in this case, ietf.org. Any p or sp tag in the ietf.org policy is
ignored, however, and treated as p=reject/sp=reject; in addition since
taugh.com has a DMARC policy, it must also have one to forward taugh.comemail.

My spam filtering now has two cases to consider: Firstly, it needs to
decide whether ietf.org is behaving legitimately, and secondly whether I
want to read mail from you.

You can put it another way, too - my proposal is essentially saying that
the From dictates failure policy, reporting, and handling, but the Sender
is used for enforcement.

One additional thing is required from MUAs, though, which is to ensure the
UI clearly shows that the message is not sent by you (directly, at least);
this allows a human reader to easily see it's a mailing list message - or
for that matter easily see it's from an unexpected sender.

Dave.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Apr 2014 13:50:30 +0300

On Apr 17, 2014, at 9:35 AM, Dave Cridland <[email-masked]> wrote:

> How do I distinguish the nice mailing lists at ietf.org from random evil spammer domains sending spam with List-ID headers?
> 
> Every proposal I've seen like this ends up tripping over the fact that there is no technical way to distinguish between mail from real mailing lists and spam that looks like it's from mailing lists.  Hence you need a whitelist for the real mail, at which point all of the mechanism beyond the key for the whitelist (probably a DKIM signature) is superfluous.
> 
> 
> There's no more need for whitelist here than on DMARC mail as things stand, of course, but it does mean that senders need tracking as well as authors, and senders need to be explicit and reliable. I'd assume reputation services (of which whitelists are just an extreme case) would be in play regardless.
> 
> Right now, my MUA treats this as a message "From John R Levine <[email-masked]>". This means that any policy on the message origination comes from looking solely at the taugh.com domain. We'll pretend it has a DMARC policy. Herein lies the Yahoo/DMARC issue, because unless your policy essentially stipulates that the IETF is allowed to spoof you, we're stuck.

<disclaimer> speaking only as an end-user here </disclaimer>

Then perhaps this is what needs to change. John R Levine did not send you a message. He sent a message to the list. It is the list software that sent you a message. So perhaps the From field should have been “From: IETF Mailing list on behalf of John R Levine <[email-masked]>”. The Reply-To could be set to either John’s real address or the mailing list address, depending on what we think users mean when they click “Reply” - reply to John or reply to the list.

Yoav

---

From: "John R Levine" <[email-masked]>
Date: 17 Apr 2014 08:29:08 -0400

>> The magic token has to be cryptographically tied to the contents of the 
>> original message
>

Now I'm totally confused.  How does that help me as a sender distinguish 
between a good mailing list that is resending real mail from Yahoo and an 
evil mailing list that is sending phishes?

Regards,

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Apr 2014 15:11:34 +0200 (CEST)

Yoav Nir wrote:
>> Right now, my MUA treats this as a message
>> "From John R Levine <[email-masked]>". This means that any policy
>> on the message origination comes from looking solely at the taugh.com
>> domain. We'll pretend it has a DMARC policy. Herein lies the
>> Yahoo/DMARC issue, because unless your policy essentially stipulates
>> that the IETF is allowed to spoof you, we're stuck.
> 
> Then perhaps this is what needs to change. John R Levine did not send
> you a message. He sent a message to the list. It is the list software
> that sent you a message. So perhaps the From field should have been
> ?From: IETF Mailing list on behalf of John R Levine <[email-masked]>?.

But that is EXACTLY what the IETF mailing list exploder *IS* doing
exactly as it has been specified for ages:

https://tools.ietf.org/html/rfc822#section-4.4.2
https://tools.ietf.org/html/rfc822#appendix-A.2

https://tools.ietf.org/html/rfc5322#section-3.6.2

            The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message. 

  From: Yoav Nir <[email-masked]>
  Subject: Re: (DMARC) Why mailing lists are only sort of special
  Errors-To: [email-masked]
  Sender: ietf <[email-masked]>
  Date: Thu, 17 Apr 2014 13:50:30 +0300
  Message-ID: <[email-masked]>
  To: Dave Cridland <[email-masked]>
  CC: "[email-masked]" <[email-masked]>

Something as old as Outlook 2003 will properly display a message
that is received with a "Sender:" as "<Sender> on behalf of <From>"

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Apr 2014 16:26:52 +0300

On Apr 17, 2014, at 4:11 PM, Martin Rex <[email-masked]> wrote:

> that is received with a "Sender:" as "<Sender> on behalf of <From>”

A client as new as Mail.app on Mac OS X 10.9 does not. 

Obviously the Sender: field is not where the DMARC implementations use for checking policy.

Yoav

---

From: Dave Cridland <[email-masked]>
Date: Thu, 17 Apr 2014 14:38:53 +0100

On 17 April 2014 11:50, Yoav Nir <[email-masked]> wrote:

> Then perhaps this is what needs to change. John R Levine did not send you
> a message. He sent a message to the list. It is the list software that sent
> you a message. So perhaps the From field should have been “From: IETF
> Mailing list on behalf of John R Levine <[email-masked]>”. The Reply-To
> could be set to either John’s real address or the mailing list address,
> depending on what we think users mean when they click “Reply” - reply to
> John or reply to the list.
>
>
What you're changing there, as Martin Rex hints, is not the semantics of
mailing lists, but the semantics of RFC 822 and successors. I could go
along with this if RFC 5322 were demonstrably broken; but in practise, it's
not.

John R Levine, in this instance, did indeed not send me the message - which
is why the Sender header field doesn't have his name or email address
present.

He did, however, write the message, which is why the From header field does.

If you want explicit handling, what we'd need to do is individually (and
visibly) authenticate each transaction - this has knock-on effects in how
we handle blind carbon-copies (in particular, we'd need to send them as a
separate transaction). This has some nasty implications for unsuspecting
MUAs; but some MUAs do this anyway for other related reasons. Also, I
suspect this model would have serious implications for DMARC - that is, I
don't think it fits the DMARC model closely enough to satisfy even
"minimal" changes to the deployed base.

But what this would do, loosely, is have a verifiable chain of
Levine->list; list->me. I would then look at the policies for Levine, and
for the list, and somehow combine them to a decision.

Dave.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 17 Apr 2014 14:43:50 +0000

> From: ietf [mailto:[email-masked]] On Behalf Of Yoav Nir
> Sent: Thursday, April 17, 2014 9:27 AM
> To: [email-masked]
> Cc: [email-masked]
> >>> Right now, my MUA treats this as a message "From John R Levine
> >>> <[email-masked]>". This means that any policy on the message
> >>> origination comes from looking solely at the taugh.com domain. We'll
> >>> pretend it has a DMARC policy. Herein lies the Yahoo/DMARC issue,
> >>> because unless your policy essentially stipulates that the IETF is
> >>> allowed to spoof you, we're stuck.
> >>
> > Something as old as Outlook 2003 will properly display a message that
> > is received with a "Sender:" as "<Sender> on behalf of <From>"
> 
Yoav, this is by design. 

There is no reliable way to determine the relationship between the Sender:field and the From: field from an authentication and authorization perspective at the domain level unless both are within the same domain space. Other than "I say so", how do we know that the Sender IS truly acting on behalf of the author in the From field where they are not both in the same domain space? This is the crux of the debate that has been going on for quite a few years. As a receiver, on what basis can I trust the sender is authorized in this circumstance? John says, "trust the mail (is on behalf of the author because you trust me". This actually has worked in the real world for some time but has been under increasing pressure due to abuse. While mailing lists have not been a significant vector in the past (John says never, I say I have seen abusive mail passed through lists so never is not true), that is not to say they will not be a significant vector.

Some people are unhappy that DMARC ties identity to the From:field. Identity could just as easily have been tied to the Mail From:field but there still would have been a need for alignment ( going the other way) and ultimately there still would have been an issue with the Sender:field if the goal is to provide a model for authentication/authorization that does not have significant defects allowing abuse (and again we are only talking about the problem space of direct domain abuse, not phishing or spam in general). The only reason for alignment is because of the use of both IP based (transport layer) and message based (requiring examination of the message body) authentication.

The problem with an approach of trying to identify trust relationships between domains (let alone authors and domains acting on behalf of individual authors at other domains) is that it is not a linear relationship. That is, the complexity of potential trust relationships does not increase in a linear fashion as we add more users and domains to the equation. There are other/easier ways of approaching the stated goal of authentication/authorization.

In going back and re reading RFC 822 (1982), RFC 2822 (2001) and RFC 5322 (2008), I notice a small but important change between RFC 822 and RFC 2822. RFC 822 actually specified "This field contains the authenticated identity..." for both the From:field and Sender:field among others. I followed the discussion for RFC2822 but was not an active participant. I don't remember significant discussion on this change but there may have been some. If this requirement had been maintained AND had been implemented, it is quite possible we would be having a different discussion today.

In the examples given in RFC822 for use of Sender:Field, where a domain name is used, all of the Sender:field email address Domains (someone please validate this as I went through the "A." examples once and somewhat quickly) were the same as the From:field email address domains although there were examples where the Sender:Field display name domain was different. On a side note, for the next update it might be appropriate to drop the word "secretary" and substitute "assistant" in the example given - a nit but appropriate nonetheless. 

So it's clear that contrary to some assertions that we have today's issues with email because authentication/security was not thought of, there was in fact some consideration given to authentication/security in the original specification. 

Just a few thoughts.

Mike

---

From: Pete Resnick <[email-masked]>
Date: Thu, 17 Apr 2014 09:49:46 -0500

On 4/17/14 7:29 AM, John R Levine wrote:
> Now I'm totally confused.  How does that help me as a sender 
> distinguish between a good mailing list that is resending real mail 
> from Yahoo and an evil mailing list that is sending phishes?

We're now *way* into technical discussion. Let's take those to 
https://www.ietf.org/mailman/listinfo/dmarc shall we?

pr

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 17 Apr 2014 11:30:43 -0400

MH Michael Hammer (5304) wrote:
> There is no reliable way to determine the relationship between the Sender:field and the From: field from an authentication and authorization perspective at the domain level unless both are within the same domain space. Other than "I say so", how do we know that the Sender IS truly acting on behalf of the author in the From

Well - if the originating system were to include To: in the signature, 
and it matched Sender: that would go a long way.

Miles Fidelman

---

From: [email-masked]
Date: Thu, 17 Apr 2014 09:11:55 -0700 (PDT)

> https://www.ietf.org/mailman/listinfo/dmarc shall we?

How about we take it some place else? I really don't want this intermingled
with discussions of things like how to revise the current DMARC specifications
that hopefully are taking place on that list.

This is especially true if you're talking about what I think you're talking
about: Senders discovering additional semantics of the recipients they are
sending to and then decorating the message accordingly. This is a fairly
radical idea which, if it pans out, may well have utility extending far beyond
DMARC.

				Ned

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 17 Apr 2014 12:28:01 -0400

> that hopefully are taking place on that list.

Any proposal as to where?

For that matter, any proposal on where to take the parallel discussion 
of process issues and IETF role?

Miles Fidelman

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Apr 2014 20:18:15 +0200 (CEST)

> reason to think that the result would be any different.

I fail to understand where the problem comes from.  The idea/architecture
of the rfc822 "sent on behalf of" (Sender:) seems clear.  If anything
should be authenticated at all, then it is what _the_sender_ decides
to send.

The sender might be asserting the authorship of the message (plus or
minus a few bits) to someone else by including the authors name in
a From: field that differs from the Sender: field.

A technology that is obsessed about the contents of the From:-Field
of an rfc822/2822/5322 Email message that ignores the semantics of
the Sender: field appears broken to me.  A sender that received
the original EMail with a signature might indicate so (and authenticate
this indication), but unless the original message is included verbatim
an opaque blob, the original signature may no longer work -- such as
when a mailing list software cleans/streamlines submissions, so the
original signature should be stripped.

MUAs which are not implementing the rfc822/2822/5322 "on behalf of"
semantics of a message that carries both From: and Sender: header
fields ought to be FIXED.  Standards that build on rfc822/2822/5322
and do not respect "on behalf of" semantics of messages with
both "Sender:" and "From:" also need to be FIXED.

-Martin

---

From: [email-masked]
Date: Thu, 17 Apr 2014 11:33:56 -0700 (PDT)

> Any proposal as to where?

Not really. AFAIK there isn't an IETF list devoted to the discussion
of anything closely related to this topic. Of course we could use
an existing list like ietf-822 or even the appsarea list, but they
somehow don't seem quite appropriate.

				Ned

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Apr 2014 12:20:40 -0700

> both "Sender:" and "From:" also need to be FIXED.

Dear Martin,

Merging Sender and From header fields by MUAs offers no protection when actual sources of messages remain unknown.  ESPs would rather see various authorization schemes than actually offering a means to authenticate their domain responsible for introducing the message.  When there is phishing or spoofing detected, those introducing messages into the public mail stream must respond by removing access, but they would rather push the problem onto their recipients.

John Klensin has already indicated TLS has a problem at authenticating sending MTAs, the clients.  We now have http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane. The next step should be to permit DANE verification of the sending MTA and allow SMTP to become fully federated.

In the meantime, there is a way for From header field domains to publish a list of third-party services employed by their users.  This can be done in the form of hash labels that can even be secured using DNSSEC.  This information could then be used to permit meaningful policy exceptions where each provider is expected to act responsibly.

The actions of a few ESPs should not result in such meaningless reaction.

Regards,
Douglas Otis

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Apr 2014 22:22:59 +0200 (CEST)

Douglas Otis <[email-masked]> wrote:
> 
> Martin Rex <[email-masked]> wrote:
>> 
> Merging Sender and From header fields by MUAs offers no protection
> when actual sources of messages remain unknown.

This is *NOT* about protection or authentication, this is purely about
rfc822/2822/5322 message semantics.  Something that has been well-defined
and constant for decades.

At the beginning of this Email there are two quotations with assertions
of authorship.  There really is no difference to the name in the From:
field of an EMail that is carried with a different Sender (and envelope
MAIL FROM:) through an SMTP transport system.

There is no difference in semantics between the assertions above
and the rfc822-header assertion in "From:", when an rfc822 message
is transferred through an SMTP MTA system in an "on behalf of" scenario
with a differing Envelope "MAIL FROM" & matching Sender: rfc822-header.

-Martin

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2014 16:34:25 -0400

> and constant for decades.

I have considerable sympathy in theory for your viewpoint, but in 
practice, the Sender header was deprecated a long time ago.  Most MUAs 
ignore it, the few that don't display it in a way that just confuses people.

-- 
Regards,
John Levine, [email-masked], http://jl.ly
Please consider the environment before reading this e-mail.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Apr 2014 13:39:01 -0700

> https://www.ietf.org/mailman/listinfo/dmarc shall we?
Just sent you the formal request for a non-WG mailing list, so as Ned
suggests (and I agree) the discussion can be separate.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2014 16:47:26 -0400

How about ietf-smtp?  It already exists and isn't very busy.

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Apr 2014 22:54:59 +0200 (CEST)

> ignore it, the few that don't display it in a way that just confuses people.

According to _what_ standard do MUAs interpret the semantics of
EMail then?

AFAIK, the relevant standard that the IETF published for this
purpose is rfc5322, and in that specification, Sender: is alive
and kicking just the way it has been since rfc822.

                   If the originator of the message can be indicated
   by a single mailbox and the author and transmitter are identical, the
   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
   appear.

Now if you're wonding what that "SHOULD" in there means,
there is a reference to rfc2119 at the beginning of rfc5322,
(a pretty common reference in IETF specifications...)

  https://tools.ietf.org/html/rfc5322#section-1.2.1

   1.2.1.  Requirements Notation

   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
   NOT", and "MAY" appear capitalized, they are being used to indicate
   particular requirements of this specification.  A discussion of the
   meanings of these terms appears in [RFC2119].

which leads to

   https://tools.ietf.org/html/rfc2119#section-3

   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

MUAs that goof the semantics of the "Sender:" header field are either
not implementing EMail the way it has been specified by the IETF,
or they goofed the second part of the above explanation for SHOULD.

-Martin

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2014 17:01:52 -0400

> or they goofed the second part of the above explanation for SHOULD.

I wouldn't disagree.  If you can find an Internet where everyone 
correctly implements every RFC, I'd sure like to see it.  In the 
meantime, we're stuck with the one we have.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Apr 2014 18:16:32 -0400

> a From: field that differs from the Sender: field.

So, the bug is that Yahoo/DMARC/ are authenticating the From:, when it should
really be authenticating the Sender:. DMARC should key it's policy from
Sender: rather than From, and if it did that then:
  1) we could leave the From: intact, which is what's good for the end
     users.
  2) the list would change the Sender:, which is what we would establish
     the reputation of the list, not the From:
  3) MUAs would compare the From: and Sender:, and if they differed,
     could say useful things like:

     "From: [email-masked] via [email-masked]".

(I was also wondering this morning on my commute if a layer of message/rfc822
added by the mailing list might be a useful interim hack)

    > both "Sender:" and "From:" also need to be FIXED.

Is "on behalf of" part of the specification...  not literally using those
words, which is a shame, because I think that it's really good wording.
section 3.3.6 says:

   The resent originator fields indicate the mailbox of the person(s) or
   system(s) that resent the message.  As with the regular originator
   fields, there are two forms: a simple "Resent-From:" form, which
   contains the mailbox of the individual doing the resending, and the
   more complex form, when one individual (identified in the "Resent-
   Sender:" field) resends a message on behalf of one or more others
   (identified in the "Resent-From:" field).

--
]               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: Michael Richardson <[email-masked]>
Date: Thu, 17 Apr 2014 18:17:52 -0400

> qualify for DMARC whitelisting, I'd think you'd want a small set (maybe only
    > one) of public whitelists.

    > big gorilla who can afford to create a whitelist can apply DMARC policies.

I don't understand whitelists.

Are you saying that gmail and yahoo have to know about my lists.sandelman.ca
before I can have gmail/yahoo members on my little local list?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Apr 2014 18:20:45 -0400

Dave Cridland <[email-masked]> wrote:
    > Right now, my MUA treats this as a message "From John R Levine <[email-masked]
    >> ". This means that any policy on the message origination comes from looking
    > solely at the taugh.com domain. We'll pretend it has a DMARC policy. Herein
    > lies the Yahoo/DMARC issue, because unless your policy essentially stipulates

If, when sending to [email-masked], taugh.com knew that it was a mailing list,
then it could include, in the message, a signed delegation saying that it was
okay for *this message* for ietf.org to impersonate him.

This is a simple application of cryptographic methods.  Keynote and SPKI
(and I think SASL) define ways to do this.

---

From: "John R Levine" <[email-masked]>
Date: 17 Apr 2014 20:10:29 -0400

> before I can have gmail/yahoo members on my little local list?

Yeah.  It's clear from the DMARC summary reports I'm getting that the big 
mail systems already have a pretty good idea of where the mailing lists 
are, so it should be possible to pre-seed a whitelist so most people 
won't have to explicitly apply unless something screws up.

I agree this idea is not great, but all the plausible alternatives seem 
even less great.

Regards,

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 17 Apr 2014 21:11:31 -0400

John R Levine wrote:
> Yeah.  It's clear from the DMARC summary reports I'm getting that the 
> big mail systems already have a pretty good idea of where the mailing 
> lists are, so it should be possible to pre-seed a whitelist so most 
> people won't have to explicitly apply unless something screws up.
>
The big buys already have whitelists - and an awful lot of our mailing 
lists are already on them.  (Every 6 months or so, some large site 
blocks our IP, I go to their postmaster site, fill in the form, and 
every is copacetic again).  The folks who are honoring DMARC p=reject 
are clearly ignoring whitelists that THEY ALREADY HAVE!

Miles Fidelman

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2014 01:29:34 -0000

>it to me.

I still think it has security holes but it's worth arguing about, so
I'll follow up on ietf-822, which seems relevant and hasn't been very
busy.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2014 01:37:33 -0000

>that hopefully are taking place on that list.

Let's take it to ietf-822 since it seems to be about stuff we'd stick
into message headers.

R's,
John

---

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Apr 2014 07:35:02 +0300

On Apr 18, 2014, at 3:10 AM, John R Levine <[email-masked]> wrote:

> Yeah.  It's clear from the DMARC summary reports I'm getting that the big mail systems already have a pretty good idea of where the mailing lists are, 

They know about big lists. Maybe even IETF lists. But do they know about sandelman.ca? Do they know about @irtf.org?

I really don’t like specs that work well only for large companies.

Yoav

---

From: "John R Levine" <[email-masked]>
Date: 18 Apr 2014 08:30:35 -0400

> They know about big lists. Maybe even IETF lists. But do they know about sandelman.ca? Do they know about @irtf.org?

Based on the DMARC reports I get (which are quite useful, independent of 
the policy stuff), I'm fairly sure they know about my tiny lists.

> I really don’t like specs that work well only for large companies.

Of course.  Who's suggesting that, other than perhaps Yahoo?

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 08:20:55 -0700

> added by the mailing list might be a useful interim hack)

http://tools.ietf.org/html/draft-kucherawy-dmarc-base-04#section-15.1

One of the key points about DMARC's design is that it's concerned
specifically with From:.  The reason is that the content of From: is what's
typically shown to the recipient by MUAs.  If DMARC keyed off Sender:
instead, then this would work:

MAIL FROM: [email-masked]

From: [email-masked]
Sender: [email-masked]
DKIM-Signature: v=1; d=badguy.example.com; ...

If DMARC pays attention to Sender: in favor of From:, then this passes, but
what the user is shown that the message is from [email-masked] with a
DMARC pass.  Not good.

Using Sender: as the authentication key was suggested and ultimately
abandoned during both DomainKeys (RFC 4870, the predecessor to DKIM) and
Sender-ID (RFC 4406, pretty much never implemented) for this sort of reason.

>     > both "Sender:" and "From:" also need to be FIXED.

I don't believe that's standardized.  I'm also not sure we (the IETF) want
to enter into user space like MUAs, an area we have historically avoided
because we don't really have such expertise.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 18 Apr 2014 11:26:22 -0400

> Sender-ID (RFC 4406, pretty much never implemented) for this sort of reason.

Yup.  The patent license didn't help, but the fundamental problem is that 
it didn't do what users needed it to do.

Regards,

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 18 Apr 2014 11:41:56 -0400

> what the user is shown that the message is from [email-masked] with a

So what happens if MUA's, because users don't want to see the "From: "
line when it's been reset to a mailing list address, ends up showing
the users what they want, which is the original sender of the mailing
list post?  It doesn't matter how or where we encode this information,
whether it's in a comment in the rewritten From: field, or in a
"X-Really-From: " header, or in the body of the message.  If there's a
convention, whether it is in a standard or de facto, there **will** be
cases when the users really want the original From header, and then
what will the DMARC promoters do then?

Try to ram through DMARC II that forces alignment of the
"X-Really-From: " header, or whatever else we end up using?

		  	     	      	      	  - Ted

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Apr 2014 08:48:22 -0700

On Apr 18, 2014, at 8:20 AM, Murray S. Kucherawy <[email-masked]> wrote:

> On Thu, Apr 17, 2014 at 3:16 PM, Michael Richardson <[email-masked]> wrote:
> One of the key points about DMARC's design is that it's concerned specifically with From:.  The reason is that the content of From: is what's typically shown to the recipient by MUAs.  If DMARC keyed off Sender: instead, then this would work:
> 
> If DMARC pays attention to Sender: in favor of From:, then this passes, but what the user is shown that the message is from [email-masked] with a DMARC pass.  Not good.
> 
> Using Sender: as the authentication key was suggested and ultimately abandoned during both DomainKeys (RFC 4870, the predecessor to DKIM) and Sender-ID (RFC 4406, pretty much never implemented) for this sort of reason.
> 
> I don't believe that's standardized.  I'm also not sure we (the IETF) want to enter into user space like MUAs, an area we have historically avoided because we don't really have such expertise.

Dear Murray,

Agreed.  The intent behind DMARC is to protect recipients wanting to trust specific From header fields.   Not protecting them will cause customer loss for high value transactional domains.  Most just don't want the flood of spoofing reaching their inbox these high value domains attract. 

Yahoo has had other problems where many of their accounts have become compromised.  Perhaps DMARC is also seen as a method to curb complaints caused by spoofed addresses so they can better address accounts actually compromised by leveraging DMARC feedback.  This would be a poor choice in my view.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 08:48:31 -0700

> "X-Really-From: " header, or whatever else we end up using?

Any answer I give to that would be speculation.  How about this: If MUAs
evolve as a result of all of this, I would hope it's in a direction that
doesn't just create whack-a-mole for the problem DMARC is trying to solve.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 18 Apr 2014 12:02:58 -0400

> doesn't just create whack-a-mole for the problem DMARC is trying to solve.

That suggests it would be in the DMARC cartel's interest to avoid putting 
evolutionary pressure on MUAs to do things they won't like.  See you in 
ietf-822.

Regards,

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 18 Apr 2014 15:07:16 -0400

> doesn't just create whack-a-mole for the problem DMARC is trying to solve.

And I'd suggest that if MUA's do evolve in that manner, maybe it's a
hint that the problem which the DMARC cheerleaders tried to sweep away
as "not a problem" really *is* a problem that users really care about.
And I would hope that in the future, they don't once again try to do
something that only meets their own parochial interests, and ignores
everyone elses' concerns.

					- Ted

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 13:15:04 -0700

> everyone elses' concerns.

There are some rather broad brush strokes here, and I'm running out of
steam trying to keep the record straight.  I'll try once more:

As John and others have already said, DMARC works fine for specific use
cases.  It's already been in use by other large operators like Bank of
America, PayPal, Facebook, and others for quite some time, with no visible
impact.  The results for them have been very positive.  Google also has it
turned on part-way for the domain their employees use.

The difference here is that Yahoo has users that send mail where those
others do not.

-MSK

---

From: [email-masked]
Date: Fri, 18 Apr 2014 20:28:51 +0000

> The difference here is that Yahoo has users that send mail where those

This sounds like the, "Once the rockets go up, who cares *where* they
come down; it's not my department, says Werner von Braun" defense.

Like it or not, the (mis)-application of DMARC has caused some
significant pain for some parts of the Internet.  Maybe *you* don't
care about it, but some of us have to deal with the distruction that
yahoo.com has wrought.

						- Ted

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 13:36:56 -0700

> care about it, but some of us have to deal with the distruction that

I didn't say anything close to "I don't care about it", or any of the other
things you're saying above.  I'd really appreciate it if you stopped
putting words in my mouth.

-MSK

---

From: [email-masked]
Date: Fri, 18 Apr 2014 20:41:50 +0000

> putting words in my mouth.

That was an inference I made given your apparent lack of remorse in
your statements.  I apologize if that's not actually how you feel
about the situation.

Regards,

					- Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Apr 2014 08:47:37 +1200

On 19/04/2014 03:20, Murray S. Kucherawy wrote:
...
> DKIM-Signature: v=1; d=badguy.example.com; ...

So, if the From says

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

many UAs would show only [email-masked] as the sender,
but badguy could have passed DMARC, no?

This would not exactly enhance goodguy's reputation,
or Yahoo's for that matter. I realise it isn't the exploit
that Yahoo is trying to stop, but it suggests to me that
DMARC is only plugging one small hole in a very leaky dam.

    Brian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 13:51:07 -0700

> DMARC is only plugging one small hole in a very leaky dam.

Yes indeed.  The DMARC base document discusses this already, by admitting
it's not a problem DMARC can solve right away:

http://tools.ietf.org/html/draft-kucherawy-dmarc-base-04#section-17.4

It's also something that was brought up as a proposed work item for the
IETF.

-MSK

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 18 Apr 2014 17:04:28 -0400

> DMARC is only plugging one small hole in a very leaky dam.

Iif the problem is trying to protect goodguy or yahoo.com's
reputation, I wonder if a better approach would have been to have
yahoo.com issue all of its users S/MIME certificates, and then had a
DMARC-like policy requesting recipients: "if the e-mail has the From:
field of yahoo.com, and it's not an S/MIME-signed e-mail with a
yahoo.com certificate, reject the e-mail".

After all, we know S/MIME successfully passes through mailing lists,
and if in fact the message was appropriately signed using an S/MIME
cert, it would be quite natural to have the UA's display the
information from the Common Name field of the cert.

That would solve a host of problems, including the hand-wringing
around how S/MIME has lots of deployed users, but very few deployed
certs.

						- Ted

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 18 Apr 2014 17:04:40 -0400

> come down; it's not my department, says Werner von Braun" defense.

I believe the quote is ""The rocket worked perfectly except for landing 
on the wrong planet."  (or as it has been suggested "we aimed for the 
Moon, but we hit London.")

:-)

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2014 19:53:20 -0500

> DMARC is only plugging one small hole in a very leaky dam.

No kidding.  DMARC is only useful because most spammers and phishers are 
remarkably stupid.  But not all of them.

R's,
John