-- Victoriano Giralt Central ICT Services Systems Manager University of Malaga +34952131415 SPAIN

Reply-To set to Mailman-Users. Although actual work on an RFC probably would be done by a developer, there's no reason to exclude site admins and list owners, and the impact of DMARC is surely apparent to developers, admins, and owners alike, as well as to our subscribers.

Victoriano Giralt writes:

This has recently circulated in the sympa-users lists. As a proud member of both communities I think that the synergy Miles proposes could really have some impact.

Thank you for posting. Mailman as an organization (through me, the more or less official delegate to the DMARC Working Group - below, just "the WG") is well aware of Miles' proposal. In short, I'm opposed to it in current form, both personally and on behalf of Mailman.

That said, I welcome discussion and advocacy of his point of view, and if the Mailman community goes there, we can either delegate more people to advocate it or I can do my best to present the Mailman consensus as well as my own view (assuming it doesn't change in response to further advocacy :-).

The rest is tl;dr, I suppose, but it is a complete and I hope fair summary of discussion of these proposals on the dmarc@ieft.org list: http://www.ietf.org/mail-archive/web/dmarc/

Subject: [sympa-users] thoughts re. DMARC impacts Date: Mon, 27 Oct 2014 20:45:32 -0400 From: Miles Fidelman <mfidelman@meetinghouse.net>

Many of us just had to deal with the impacts of DMARC on our lists.

In the aftermath, I've been participating on the dmarc-ietf email list - trying to discuss ways to "fix DMARC" to better coexist with lists and other 3rd-party services (like "send this article to....").

Unfortunately, it seems like the discussion is bogged down in two regards:

• the ietf-dmarc working group is charted to "enhance DMARC" - dealing with its impacts is not really the focus - folks want a general purpose solution

This is false. The charter is public: http://tools.ietf.org/wg/dmarc/charters

In fact, Miles' proposal, and several similar ones, have received a lot of attention from the WG. Nobody has claimed it's out of WG scope or tried to shut down discussion on that basis, although it's "off current focus". It's true that two specific participants are strong proponents of "general purpose solutions", but they are "special interests" (a party of 2, or perhaps 2 parties of 1 ;-). The people who are the backbone of the WG have on average two *decades* of experience in creating email-related and other Internet standards, and they are quite happy to consider incremental improvements, two of which (the *-dkim-* Internet Drafts) are cited below.

Currently, the WG's focus is on figuring out just what those impacts are, it's true, and that is a "general purpose" task. Nevertheless, many members of the WG are open to "off-focus" work as individuals, and the WG wiki is open as a forum for presenting "off-focus" ideas to be addressed ad hoc by individuals or by the WG in the future. http://tools.ietf.org/wg/dmarc/trac/wiki

Personally, I'd like to see a short-term solution to make our lives easier, as list managers - sort of the way that NAT has been dealing with IPv4 address exhaustion, while we wait for IPv6 to happen.

This is an excellent analogy. NAT has caused almost as many problems as it solved, especially in the security area. Miles' proposal would be the same IMO.

I've been thinking along the lines of an update to RFC2369 - the 16-year-old document defines the List-* headers. Say by adding a couple of headers along the lines of: List-Original-Author: <the original author> List-Original-Reply-To: <the original message's Reply-To>

These two have trivial generalizations which apply to some of the other third-party issues created by DMARC. Specifically, just drop the "List-" prefix. This generalization *will* occur -- those users will perceive the utility to themselves, and just start using it. The misnaming may not cause problems, but why invite them when we don't have to?

By either name (or slight variations, such as "Original-From" and "X-Original-From" -- the latter has long been used by GMail for internal purposes, apparently), this proposal has the following design issues that must be resolved:

1. It changes the semantics of the From field defined by RFC 5322. According to RFC 5322, From is the definitive field indicating the author of the message content in a sense made somewhat precise in that RFC and other email RFCs. This proposal would add a very general "except when it isn't" clause to that definition, requiring updates to every MUA in use. It may affect many other RFCs as well -- specifically but not limited to all email authentication RFCs that propose to address the phishing problem.

2. Advocates of such headers are sharply divided on proposed semantics. Some (Google, Scott Kitterman on the WG ML) consider that the semantics should be restricted to the Reply-To function, and otherwise be invisible to end users. Miles himself clearly favors "really truly From" semantics that would encourage MUAs to make it visible.

   I believe that in practice Miles' interpretation would win, and in that case I'm quite sure that there would be zero-day exploits by phishers (unless the DMARC folks get there first by implementing DKIM signatures applied to empty Original-Author fields!)

3. No serious consideration has been given to potential new exploits or social engineering under either semantics, although the possibility of generalizing existing phishing techniques under the "really truly from" interpretation are painfully obvious.

4. No consideration has been given to precise semantics of Original-Reply-To.

5. No consideration has been given to alternative use of, or interaction with combined with, existing Resent-* fields.

6. No consideration has been given to multiple instances of the Original-* fields.

In my opinion, some of these issues (1, 2, 3) cannot be resolved satisfactorily in a reasonable amount of time, and therefore the proposal is fatally flawed as a "fast-track" IETF document. It could proceed (as DMARC itself did!) as a private agreement between mailing lists and MUA developers.

The argument that an IETF RFC would make coordination with MUA developers easier is valid but weak. The popular MUA developers do not really consider RFCs in their designs (several have told me this, including Mozilla folks). Rather, they wait for implementations to appear in wide use, and then leverage those implementations as serves their users.

List-Reply-To: <the list-specific reply-to - either author of list>

I have an old proposal related to this, with the intent of mitigating the Reply-To munging issue. (I'm not sure what Miles wants it for.) I'll dig it up. N.B. I never submitted an Internet Draft, that's when the MUA authors told me they ignore such things. :-)

Seems to me that this would:

1. give us a standard way to find the original author

Correct.

(and for HTML mail, to reply by clicking on a mailto: URL in the header)

[Aside: This feature isn't at all restricted to HTML mail. It's just a function of the MUA's presentation capabilities, and some text- oriented MUAs provide hotkeys for navigating and activating links.]

2. provide standardized information that could be used by MUAs for identifying, and presenting reply options

I don't think these fields provide any information that the RFC 5322 and RFC 2369 fields don't already contain.

The problem that this proposal is intended to address is that DMARC is designed to control where that information can be provided and bound to the message content -- specifically restricting these functions to the Author Domain's MTA. Theoretically they could authorize third parties, in practice they don't, and there's good reason to believe they won't do so soon. The problem with the proposal is that any attempt to allow the good guys (lists) to provide that information bound to altered message content[1] will provoke responses from the phishers, and from the DMARC participants.

(maybe leading to "reply to list" and "reply to author" buttons starting to show up on toolbars)

They already do (eg, Mutt and KMail). In any case the required information has long been available in the RFC 2369 List-Post field -- if an MUA hasn't implemented reply-to-list by now, its developers have their reasons for not doing so.

3. set the stage for adding some authentication mechanisms that accomplish what DMARC is intended to do (e.g. by adding a few more headers that cryptographically authenticate the new List- headers and bind them to the message body)

In fact, DKIM can *already* authenticate those headers. The problem posed by DMARC is that Author Domains[2] want to control the use of mailboxes in their domains in the From field[3], and do so by signing that field. This will not cause problems where mailboxes are for corporate convenience -- the corporation just tells its agents that they can't use those mailboxes to send to public mailing lists or for other third-party uses. Where it does cause problems is at those services which provide mailboxes for arbitrary personal use. It is precisely those services that balk at delegating signing authority, primarily due to the costs of investigating and approving third parties, and for some third-party authorization schemes, burdens on infrastructure (especially the DNS). (Here, corporations will have a for-profit or increased-benefit reason for delegation, and so will be perfectly happy to pay the costs of delegation when appropriate.)

It is already possible for Author Domains to delegate authentication of From to mailing lists and other third-party services. There is a now-mature and very elaborate proposal for a protocol similar to DMARC itself that uses the DNS to publish such authorizations on a long-term basis: http://tools.ietf.org/html/draft-otis-tpa-label and two that extend DKIM to allow message by message authorization: http://tools.ietf.org/html/draft-kucherawy-dkim-delegate http://tools.ietf.org/html/draft-levine-dkim-conditional

However, it is rather questionable whether services like Google or Yahoo! with hundreds of millions of mailboxes will be able to vet tens or hundreds of thousands of third-party services. Google and Yahoo! technical staff have already indicated on the WG list that they really would rather not.

The effective response of DMARC-using Author Domains is already known: sign empty "Original-*" fields corresponding to existing fields that are known to be useful in phishing and spoofing in general. Whether they will actually do that depends on MUA take-up and whether the spoofers exploit. That seems very likely to be highly correlated with how effective these fields are at achieving their intended purpose.

IMO, to make these proposals useful, proponents need to provide a plausible mechanism to prevent spoofing without preventing the intended use at the same time.

It strikes me that this might proceed rather quickly, if incorporated into an RFC co-authored and submitted by folks from the mailing list software community

The writing of a document might go quickly, but it takes at least a year to get to Proposed Standard status, even without IETF community opposition. Cf. DMARC itself, which is actually four or five years old by now.

(Can you say, "rough consensus and running code?")

Running code, yes, but that "rough consensus" would have to include (self-appointed ;-) representatives of *all* email users, not just the MLs. A rough consensus of a subset is exactly what got us DMARC. And those other "representatives" include a *lot* of people who take a very dim view of screwing with RFC 5322 semantics.

Reactions? Anybody want to collaborate on a draft RFC for submission through the independent submissions path? Any thoughts on who needs to be involved from the Sympa community, and/or from the other mailing list software communities?

As I say, I have an old draft for something related to List-Reply-To which I will dig up and post here for reference.[4] I won't be participating in writing up any of Miles' proposals until I've seen plausible ways to address issues 1-6 presented above. I encourage anybody who thinks that they all can be solved to do so! and to participate.

Aone piece of advice: from the point of view of Miles and other proponents, the resistance from the IETF old guard is "political". But I believe it will be strong. You could try to present it as an informational RFC ("mailing lists are doing this even though it doesn't conform to applicable standards"), but I suspect the RFC editor would delay publication until (1) the impact of this practice on conformance to email RFCs in general is described (issue 1 above must be resolved), and (2) the response of phishers and DMARC participants to the practice is visible. For this reason alone, I strongly recommend creating an ad hoc "Committee for the Preservation of Mailing Lists" or something like that, and publishing your standard independently of the RFC process.

There is precedent for this. Daniel Bernstein's "Mail-Followup-To" header is widely provided and respected by open source MUAs, both for news posts (the original application) and for email (primarily to mailing lists). Of course the pain of DMARC is mostly felt by users of the big mailbox providers (ie, not users of open source MUAs), but there you already have GMail (and maybe other webmail services, I haven't checked) using a variant of the proposal. (Warning: that doesn't mean that GMail would implement the features that you propose in the user-visible MUA! But at least they're not opposed to the header field itself.)

Good luck!

Steve

Footnotes: [1] In the sense of invalidating the first-party DKIM signature.

[2] By which I mean an organization such as Yahoo! that maintains a domain registration and MTA infrastructure, and provides mail transport services including mailbox addresses and storage to users.

[3] They have a legitimate interest in doing so, but that discussion is long since moot -- DMARC is a fact and it's not going to go away.

[4] If there's enough interest I might try to push it through the IETF process.

Reply-To set to Mailman-Users. Although actual work on an RFC probably would be done by a developer, there's no reason to exclude site admins and list owners, and the impact of DMARC is surely apparent to developers, admins, and owners alike, as well as to our subscribers.

Victoriano Giralt writes:

This has recently circulated in the sympa-users lists. As a proud member of both communities I think that the synergy Miles proposes could really have some impact.

Thank you for posting. Mailman as an organization (through me, the more or less official delegate to the DMARC Working Group - below, just "the WG") is well aware of Miles' proposal. In short, I'm opposed to it in current form, both personally and on behalf of Mailman.

That said, I welcome discussion and advocacy of his point of view, and if the Mailman community goes there, we can either delegate more people to advocate it or I can do my best to present the Mailman consensus as well as my own view (assuming it doesn't change in response to further advocacy :-).

The rest is tl;dr, I suppose, but it is a complete and I hope fair summary of discussion of these proposals on the dmarc@ieft.org list: http://www.ietf.org/mail-archive/web/dmarc/

Subject: [sympa-users] thoughts re. DMARC impacts Date: Mon, 27 Oct 2014 20:45:32 -0400 From: Miles Fidelman <mfidelman@meetinghouse.net>

Many of us just had to deal with the impacts of DMARC on our lists.

In the aftermath, I've been participating on the dmarc-ietf email list - trying to discuss ways to "fix DMARC" to better coexist with lists and other 3rd-party services (like "send this article to....").

Unfortunately, it seems like the discussion is bogged down in two regards:

• the ietf-dmarc working group is charted to "enhance DMARC" - dealing with its impacts is not really the focus - folks want a general purpose solution

This is false. The charter is public: http://tools.ietf.org/wg/dmarc/charters

In fact, Miles' proposal, and several similar ones, have received a lot of attention from the WG. Nobody has claimed it's out of WG scope or tried to shut down discussion on that basis, although it's "off current focus". It's true that two specific participants are strong proponents of "general purpose solutions", but they are "special interests" (a party of 2, or perhaps 2 parties of 1 ;-). The people who are the backbone of the WG have on average two *decades* of experience in creating email-related and other Internet standards, and they are quite happy to consider incremental improvements, two of which (the *-dkim-* Internet Drafts) are cited below.

Currently, the WG's focus is on figuring out just what those impacts are, it's true, and that is a "general purpose" task. Nevertheless, many members of the WG are open to "off-focus" work as individuals, and the WG wiki is open as a forum for presenting "off-focus" ideas to be addressed ad hoc by individuals or by the WG in the future. http://tools.ietf.org/wg/dmarc/trac/wiki

Personally, I'd like to see a short-term solution to make our lives easier, as list managers - sort of the way that NAT has been dealing with IPv4 address exhaustion, while we wait for IPv6 to happen.

This is an excellent analogy. NAT has caused almost as many problems as it solved, especially in the security area. Miles' proposal would be the same IMO.

I've been thinking along the lines of an update to RFC2369 - the 16-year-old document defines the List-* headers. Say by adding a couple of headers along the lines of: List-Original-Author: <the original author> List-Original-Reply-To: <the original message's Reply-To>

These two have trivial generalizations which apply to some of the other third-party issues created by DMARC. Specifically, just drop the "List-" prefix. This generalization *will* occur -- those users will perceive the utility to themselves, and just start using it. The misnaming may not cause problems, but why invite them when we don't have to?

By either name (or slight variations, such as "Original-From" and "X-Original-From" -- the latter has long been used by GMail for internal purposes, apparently), this proposal has the following design issues that must be resolved:

1. It changes the semantics of the From field defined by RFC 5322. According to RFC 5322, From is the definitive field indicating the author of the message content in a sense made somewhat precise in that RFC and other email RFCs. This proposal would add a very general "except when it isn't" clause to that definition, requiring updates to every MUA in use. It may affect many other RFCs as well -- specifically but not limited to all email authentication RFCs that propose to address the phishing problem.

2. Advocates of such headers are sharply divided on proposed semantics. Some (Google, Scott Kitterman on the WG ML) consider that the semantics should be restricted to the Reply-To function, and otherwise be invisible to end users. Miles himself clearly favors "really truly From" semantics that would encourage MUAs to make it visible.

   I believe that in practice Miles' interpretation would win, and in that case I'm quite sure that there would be zero-day exploits by phishers (unless the DMARC folks get there first by implementing DKIM signatures applied to empty Original-Author fields!)

3. No serious consideration has been given to potential new exploits or social engineering under either semantics, although the possibility of generalizing existing phishing techniques under the "really truly from" interpretation are painfully obvious.

4. No consideration has been given to precise semantics of Original-Reply-To.

5. No consideration has been given to alternative use of, or interaction with combined with, existing Resent-* fields.

6. No consideration has been given to multiple instances of the Original-* fields.

In my opinion, some of these issues (1, 2, 3) cannot be resolved satisfactorily in a reasonable amount of time, and therefore the proposal is fatally flawed as a "fast-track" IETF document. It could proceed (as DMARC itself did!) as a private agreement between mailing lists and MUA developers.

The argument that an IETF RFC would make coordination with MUA developers easier is valid but weak. The popular MUA developers do not really consider RFCs in their designs (several have told me this, including Mozilla folks). Rather, they wait for implementations to appear in wide use, and then leverage those implementations as serves their users.

List-Reply-To: <the list-specific reply-to - either author of list>

I have an old proposal related to this, with the intent of mitigating the Reply-To munging issue. (I'm not sure what Miles wants it for.) I'll dig it up. N.B. I never submitted an Internet Draft, that's when the MUA authors told me they ignore such things. :-)

Seems to me that this would:

1. give us a standard way to find the original author

Correct.

(and for HTML mail, to reply by clicking on a mailto: URL in the header)

[Aside: This feature isn't at all restricted to HTML mail. It's just a function of the MUA's presentation capabilities, and some text- oriented MUAs provide hotkeys for navigating and activating links.]

2. provide standardized information that could be used by MUAs for identifying, and presenting reply options

I don't think these fields provide any information that the RFC 5322 and RFC 2369 fields don't already contain.

The problem that this proposal is intended to address is that DMARC is designed to control where that information can be provided and bound to the message content -- specifically restricting these functions to the Author Domain's MTA. Theoretically they could authorize third parties, in practice they don't, and there's good reason to believe they won't do so soon. The problem with the proposal is that any attempt to allow the good guys (lists) to provide that information bound to altered message content[1] will provoke responses from the phishers, and from the DMARC participants.

(maybe leading to "reply to list" and "reply to author" buttons starting to show up on toolbars)

They already do (eg, Mutt and KMail). In any case the required information has long been available in the RFC 2369 List-Post field -- if an MUA hasn't implemented reply-to-list by now, its developers have their reasons for not doing so.

3. set the stage for adding some authentication mechanisms that accomplish what DMARC is intended to do (e.g. by adding a few more headers that cryptographically authenticate the new List- headers and bind them to the message body)

In fact, DKIM can *already* authenticate those headers. The problem posed by DMARC is that Author Domains[2] want to control the use of mailboxes in their domains in the From field[3], and do so by signing that field. This will not cause problems where mailboxes are for corporate convenience -- the corporation just tells its agents that they can't use those mailboxes to send to public mailing lists or for other third-party uses. Where it does cause problems is at those services which provide mailboxes for arbitrary personal use. It is precisely those services that balk at delegating signing authority, primarily due to the costs of investigating and approving third parties, and for some third-party authorization schemes, burdens on infrastructure (especially the DNS). (Here, corporations will have a for-profit or increased-benefit reason for delegation, and so will be perfectly happy to pay the costs of delegation when appropriate.)

It is already possible for Author Domains to delegate authentication of From to mailing lists and other third-party services. There is a now-mature and very elaborate proposal for a protocol similar to DMARC itself that uses the DNS to publish such authorizations on a long-term basis: http://tools.ietf.org/html/draft-otis-tpa-label and two that extend DKIM to allow message by message authorization: http://tools.ietf.org/html/draft-kucherawy-dkim-delegate http://tools.ietf.org/html/draft-levine-dkim-conditional

However, it is rather questionable whether services like Google or Yahoo! with hundreds of millions of mailboxes will be able to vet tens or hundreds of thousands of third-party services. Google and Yahoo! technical staff have already indicated on the WG list that they really would rather not.

The effective response of DMARC-using Author Domains is already known: sign empty "Original-*" fields corresponding to existing fields that are known to be useful in phishing and spoofing in general. Whether they will actually do that depends on MUA take-up and whether the spoofers exploit. That seems very likely to be highly correlated with how effective these fields are at achieving their intended purpose.

IMO, to make these proposals useful, proponents need to provide a plausible mechanism to prevent spoofing without preventing the intended use at the same time.

It strikes me that this might proceed rather quickly, if incorporated into an RFC co-authored and submitted by folks from the mailing list software community

The writing of a document might go quickly, but it takes at least a year to get to Proposed Standard status, even without IETF community opposition. Cf. DMARC itself, which is actually four or five years old by now.

(Can you say, "rough consensus and running code?")

Running code, yes, but that "rough consensus" would have to include (self-appointed ;-) representatives of *all* email users, not just the MLs. A rough consensus of a subset is exactly what got us DMARC. And those other "representatives" include a *lot* of people who take a very dim view of screwing with RFC 5322 semantics.

Reactions? Anybody want to collaborate on a draft RFC for submission through the independent submissions path? Any thoughts on who needs to be involved from the Sympa community, and/or from the other mailing list software communities?

As I say, I have an old draft for something related to List-Reply-To which I will dig up and post here for reference.[4] I won't be participating in writing up any of Miles' proposals until I've seen plausible ways to address issues 1-6 presented above. I encourage anybody who thinks that they all can be solved to do so! and to participate.

Aone piece of advice: from the point of view of Miles and other proponents, the resistance from the IETF old guard is "political". But I believe it will be strong. You could try to present it as an informational RFC ("mailing lists are doing this even though it doesn't conform to applicable standards"), but I suspect the RFC editor would delay publication until (1) the impact of this practice on conformance to email RFCs in general is described (issue 1 above must be resolved), and (2) the response of phishers and DMARC participants to the practice is visible. For this reason alone, I strongly recommend creating an ad hoc "Committee for the Preservation of Mailing Lists" or something like that, and publishing your standard independently of the RFC process.

There is precedent for this. Daniel Bernstein's "Mail-Followup-To" header is widely provided and respected by open source MUAs, both for news posts (the original application) and for email (primarily to mailing lists). Of course the pain of DMARC is mostly felt by users of the big mailbox providers (ie, not users of open source MUAs), but there you already have GMail (and maybe other webmail services, I haven't checked) using a variant of the proposal. (Warning: that doesn't mean that GMail would implement the features that you propose in the user-visible MUA! But at least they're not opposed to the header field itself.)

Good luck!

Steve

Footnotes: [1] In the sense of invalidating the first-party DKIM signature.

[2] By which I mean an organization such as Yahoo! that maintains a domain registration and MTA infrastructure, and provides mail transport services including mailbox addresses and storage to users.

[3] They have a legitimate interest in doing so, but that discussion is long since moot -- DMARC is a fact and it's not going to go away.

[4] If there's enough interest I might try to push it through the IETF process.