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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Hence you can only accept mutated messages from sources you trust, i.e., a whitelist, and once you have a whitelist, you might as well just deliver the whitelisted mail. Maybe I'm missing something here, but we've gone around this barn an awful lot of times over the past decade and always ended up in the same place.

R's,
John

<<attachment: smime.p7s>>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]