On 5 Dec 2020, at 13:03, John Levine wrote:
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.
I’d like to step back from the specific use case of “a bank”.
If a domain publishes p=reject, they’re requesting particular handling
of a message they originate. ARC modifies that, which is good for
mailing lists and similar intermediaries, but depends on a list of
trusted intermediaries that is not under the control of the originating
domain. That increases the attack surface for DMARC considerably.
The question I have is: Should DMARC have a policy (or policy modifier)
that says, “Do not accept modifications to this message?” In other
words, that the originator values the integrity of their messages over
deliverability.
-Jim
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
