On 12/5/20 1:03 PM, John Levine wrote:
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.
There is no guarantee of that. If my bank says reject that mail, I want
my provider to reject that mail, period. No amount of ARC shenanigans
should change that policy.
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.
I'm not talking about misconfigured mail systems. I'm talking about a
policy state that is not in the current set of p values.
Mike
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
