search

msimerson / mail-dmarc

Mail::DMARC, a complete DMARC implementation in Perl
Other
33 stars 23 forks source link

Possible issue with ARC-signed emails #210

Closed bigio closed 1 year ago

bigio commented 1 year ago

Hi, when an email is DKIM signed and later modified, the MTA can ARC sign the email, this way the invalid DKIM signature is not considered and DMARC policy can be overridden because of ARC (https://www.rfc-editor.org/rfc/rfc8617.html#section-7.2.1). In PurePerl code however DKIM signatures are checked only if the organization domain matches, this happens very rarely when a message is ARC signed. Can Mail::DMARC be improved in order to better support ARC signed messages ?

marcbradshaw commented 1 year ago

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 commented 1 year ago

Thanks for the details.