Whitelisting mailing well-behaved mailing lists is a hole, but not in general a horrible one; the problems are receiver consistency, scaling and maintenance, and they are pretty intractable.
One variant of the minimal DKIM signature which has been suggested to me is to double-sign, with a minimal signature and a protective one using two different selectors. That is currently pointless (if not actually dangerous, because it's very implementation-dependent what receivers will do in this situation), but there are some possible forward paths from there. I don't think I'm enthused, but it's a novel concept. A mailing-list and receiver change option that has also been suggested to me is to have mailing lists include the original message as a MIME component -- you can then verify the signature on the original message and do some kind of comparison to the new one and decide how you feel about it. Again, it's a future-work solution. Elizabeth zwi...@yahoo-inc.com From: Brandon Long <bl...@google.com<mailto:bl...@google.com>> Date: Friday, May 30, 2014 at 1:13 AM To: "dmarc@ietf.org<mailto:dmarc@ietf.org>" <dmarc@ietf.org<mailto:dmarc@ietf.org>> Subject: [dmarc-ietf] Yet another mailing list solution thread What can DMARC enforcing domains do right now: 1) Whitelist mailing lists from enforcement. This is obviously a hole in DMARC which lowers the overall utility. Its basically saying "we don't trust your p=REJECT, we'll sometimes downgrade it to p=QUARANTINE". 2) Put a really simple DKIM signature on messages which doesn't cover the subject/body. Ick, but it could theoretically be done. The Future 1) Support Original-Authentication-Results. This requires the MLM to add them in the first place, and for the DMARC enforcing domains to check them. Has an open question of how best to "trust" the OAR header on a message. Options there are explicit whitelists from the sending domains (tpa-labels or whatever) or to leave it up to the individual receiving domain. 2) A new mailing list specific DKIM canonicalization. Its unlikely to be possible to be 100% authentication, its open for debate whether we could come up with one that'll provide some level of auth that may be useful in a more complicated "spam/phishing evaluation". 3) Some sort of "permission to relay" token. This is pretty similar to the DKIM above. 4) Plain old whitelisting (tpa-labels or whatever). Personally, I think without AuthRes/OAR, this is too big a hole to be useful. 5) More radical changes to MLMs/clients such as defining new headers with associated client requirements (ie, the footer / subject prefix is theoretically redundant with the adoptions of List-* headers). Other alternatives include embedding the original message in a wrapper (a message/digest of one). Are there any other clients besides mutt which handle this well? Other ideas? Brandon
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
