Re: [dmarc-ietf] ARC vs reject

[John Levine <[e-mail]>]

In article <[e-mail]> 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