One would be a spec revision to deal with ARC. Does DMARC still 'fail'? Yet the whole point of ARC is to create the possibility of still getting delivered, in spite of this.My position on this is that the decision by a validator/mailbox provider to use ARC and accept mail that would otherwise fail DMARC falls under the heading of "local policy". There does not need to be a spec revision to deal with ARC from this perspective. A sending domain publishing a DMARC policy is expressing it's wishes, not making demands (it cannot enforce). This is true with respect to any local policy a validator/mailbox provider implements.
If a domain publishes a "p=reject/quarantine" (restrictive policy), the published intent and expectation is to reject or quarantine failures. If the receiver wishes to further relax how it handles failures, that would be a specific local policy, not "general policy." Overall, the protocol intent is to Reject/Quarantine.
The ARC question is how does ARC change this existing "psuedo-standard" protocol logic?
I prefer an explicit DMARC extended tag (or a author domain ARC seal) that publishes the domain intent to use ARC to relax "some" p=reject/quarantine failure in some fashion which is not defined at the moment. The preference is to remove/reduce receiver ambiguity of what is to be expected when DKIM/DMARC is augmented with the ARC.
-- HLS _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
