[Mailman-Users] DMARC and Reply-To lines with from_is_list munging.

[Lindsay Haisley]

On Sat, 2014-05-10 at 02:13 +0000, John Levine wrote:
> >Arguably, the correct response to DMARC filtering _should_ be the MIME
> >encapsulation of list mail, with appropriate RFC 2369 headers added to
> >the enclosing MIME structure leaving the content un-munged, with all
> >information from the original poster intact.  Arguably, MUAs should be
> >transparent to this.  Arguably, this would have been the best design for
> >the operation of mailing lists in email-space from the git-go.
> 
> Unfortunately, this argument falls over when you note that spammers
> and phishers can encapsulate their paypal.com phishes and add list
> headers, too.  

There are no headers, except the local mail server's Received header,
that can't be spoofed.  The point here is that currently the response of
MUAs to Content-Type: multipart/mixed or Content-Type: multipart/rfc822
varies widely, so that the Mailman option of "Wrap Message" becomes
problematic for some recipients.  My iPhone deals with it, but opening
the actual content containing the list post requires an extra step.
Some MUAs, such as Evolution, open the contained email by default,
presenting a double set of headers - those of the wrapper and those of
the contents.  What I'm suggesting is functionally, from the point of
view of DMARC, identical to Mailman's current "Wrap Message" method, but
would standardize the way contents are presented, eliminating a bit of
the geekyness which some MUAs require.  

Stephen's point, and yours too as I take it, is that making it too easy
and transparent to read wrapped email essentially legitimizes the social
misbehavior of ESPs which have implemented DMARC, and Stephen has
underlined the pie-in-the-sky-ness of the idea by pointing out that it
will be a sub-zero day in Hell when the authors of MUAs would go along
with such an idea.  

As an email system administrator I've watched a lot of misbegotten
attempts on the part of a lot of ESPs to fight spam and phishing, many
of them breaking email (and email RFCs) in the process.  It seems to me
though, that adding a largely transparent extra layer of MIME
encapsulation to email, with a predictable result on the MUA end, would
be a good point from which to start.  It's analogous to double-boxing
delicate items when shipping them. 

> The correct response is either for senders to stop publishing DMARC
> policies that don't match the way their users use mail (fat chance),
> or for recipient systems to skip the DMARC checks on mail from sources
> that are known to send mail that recipients want but that doesn't
> match DMARC's narrow authentication model, e.g., mailing lists and the
> Wall Street Journal's mail-an-article button.
> 
Agreed, but in the Real World spam and phishing have been persistent
problems since the early 90s.  The fundamental problem is the shifting
of the cost of email onto the receiver, and no method yet devised has
successfully dealt with it.  The original email protocols, starting with
RFC 822, didn't anticipate it.  It is quite arguable that DMARC contains
some sensible and effective elements to address the issue of email
authentication, which is ultimately where the whole process needs to go.
This is quite apart from the ham-handed attack on network neutrality
demonstrated by the present implementation of it by Yahoo and AOL.  As
Stephen (I think) pointed out, the use of DMARC by PayPal and a number
of banks is the correct way that it should be used.  As you rightly
point out, recipient systems should skip the DMARC checks on mail from
sources that are known to send mail that recipients want but that
doesn't match DMARC's narrow authentication model.  Nonetheless a narrow
authentication model of some sort may be what's needed here.

-- 
Lindsay Haisley       | "Everything works if you let it"
FMP Computer Services |
512-259-1190          |     - The Roadie
http://www.fmp.com    |