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