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

> 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

smime.p7s
Description: S/MIME Cryptographic Signature