In article <[email protected]> you write: > >As I understand ARC, it is means of transporting the original auth-res >to the destination in case the origin signature is broken by an >intermediary. From there the destination can decide one way or the other >to override the DMARC policy of, say, reject.
Right. >There are, however, use >cases where that is exactly wrong and in no case does the originating >domain want such an override to happen. Consider my bank sending me >transactional email. If somehow somebody managed to get that mail >through a mailing list and arc-resigned it, my bank does *not* want that >mail to be delivered regardless of the reputation of the mailing list >because something weird and wrong is happening on its face. If you get a message from a bank via a trustworthy mailing list with a valid ARC chain that starts with a DMARC pass, that means someone at the bank really did send the message to the list. I don't think it's our job to try to guess whether the bank's users are following some internal policy we can't see. In practice, I can tell you that many organizations publish p=reject because it is "more secure" and have no clue about mailing lists, so it's a feature that ARC lets their users participate in mailing lists without totally ignoring their DMARC policy. Ditto organizations that publish p=reject and only have SPF, no DKIM, so all of their mail fails when it's forwarded. I can tell you this latter situation happens a lot, particularly in US government organiations where DMARC is just another checklist item. R's, John _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
