Possible issue with ARC-signed emails

[bigio]

Possible issue with ARC-signed emails

[marcbradshaw]

Hi,

I don't think there is anything to do in the Mail::DMARC layer to support this.

ARC should be considered as an additional step to DMARC, and should not modify how DMARC is processed. That is, ARC may be used to reason about why a DMARC fail should be overridden, but MUST NOT cause a message that would otherwise have failed DMARC to pass. This can be expressed in reporting using the evaluated disposition and comment field (and will be improved with adoption of DMARCbis). This is as described in sections 7.2.1 and 7.2.2 of rfc8617 as you mentioned.

Senders, especially those consuming DMARC reports would be confused by reports where a DMARC fail is reported as a pass due to a local policy decision (such as ARC).

For an example of how this works in practice see https://github.com/fastmail/authentication_milter/blob/master/lib/Mail/Milter/Authentication/Handler/ARC.pm and the associated DMARC handler module.

The simplified flow for overrides here is to walk back over the ARC seals, and when the sealer is trusted (how you define that trust is up to you, but reasonable due diligence should be undertaken) re-evaluate DMARC based on the DKIM and SPF state asserted by the trusted ARC sealer in the relevant AAR header, and override DMARC accordingly.

It is important to state here, that the mere presence of an ARC set should never be taken as a blanket override for DMARC. The asserted authentication state in the AAR headers should be used, that state should be used to re-evaluate DMARC, the original DMARC result should be overridden but the original state should be reported, and in all of this the trust model is important.

[bigio]

Thanks for the details.