A DKIM signature acts like a notary public, "This person, who is well known to me, can be reliably associated with this document."
Signing works for DMARC only when the DKIM signer has actually validated the entity before adding the signature. Therefore, when a signature is applied by an outbound gateway server, everything depends on whether the gateway was able to authenticate the message being signed. I know of no discussion about how a gateway authenticates its clients and how an evaluator knows that the signature was applied to an authenticated message. This is relevant for at least Outlook.com. It does not enforce SPF on incoming messages, but does assume that the incoming identity is valid. It then adds a signature for the purported client, using either "<clientproxy>.onmicrosoft.com" or the actual client domain, depending on the client's DNS configuration. This can produce false DMARC Pass, sometimes with Dual Authentication. This attack strategy has been observed in the wild. Fortunately, Outlook.com applies an ARC set for every pass through its environment. As a result, messages from Outlook.com should apply DMARC to the i=1 ARC set rather than the Mail From, Source IP and DKIM status at reception. More generally, a message should only be considered DMARC-validated if it can be validated at every organization change. There are many obstacles to making that determination. ARC is clearly part of the solution. Doug Foster
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
