Re: (DMARC) We've been here before, was Why mailing lists

[[e-mail] (Martin Rex)]

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


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