[Mailman-Developers] Fwd: [sympa-users] thoughts re. DMARC impacts

[Stephen J. Turnbull]

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 at 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 at 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.