>
> We can and should provide an intermediate policy option, if we concentrate
> on the principle that both authentication and repudiation require
> confirming evidence.  Repuudiation is not the simple opposite of
> authentication.   To this date, our choices have been limited because
> DMARCv1 did not design repudiation rules, but we can.
>
> The aligned DKIM signature test can have three conclusions, not just two:
>
> ·         Fully Authenticated:    A signature is present, a DNS public
> key is available, and the key can be used to verify the signature.
>
> ·         Provided:  A signature is present, and a DNS public key is
> available, but the key cannot be used to validate the signature.
>
> ·         No Signature or No key:  A signature is not present or is
> present but the DNS public key is not available.
>
> If the domain owner indicates that all messages originate with a
> signature, then messages with “No Signature or No Key” are verifiably not
> from the domain owner and can be confidently repudiated.
>
> Similarly, SPF checks can provide multiple levels of granularity:
>
> ·         Fully authenticated:   An SPF policy is found, it evaluates to
> PASS, and the MAILFROM and FROM domains are aligned.
>
> ·         Well-identified source:   An SPF policy is found, it evaluates
> to PASS, but the MAILFROM and FROM domains are not aligned.
>
> ·         Valid Identifier:  An SPF policy is found.
>
> ·         No policy:   An SPF lookup returns or NXDOMAIN.
>
> We can provide a repudiation test based on Valid Identifier.   Some
> forwarders will forward without MAILFROM rewrite, in which case SPF will
> fail, but the Valid Identifier test will pass.   Other forwarders will
> perform MAILFROM rewrite to ensure SPF PASS.  In either case, it is
> reasonable to conclude that all forwarded messages wiill pass the “Valid
> Identifier” test.
>
> Consequently, a DMARCbis policy focused on “no false rejections” will look
> like this:
>
> ·         Authenticated (unchanged):
>
> o   SPF PASS and aligned, or
>
> o   DKIM verified and aligned.
>
> ·         Repudiated (new):
>
> o   No DKIM signature or no DNS key for the signature, when the domain
> owner indicates that DKIM signatures are always present
>
> o   No SPF policy (NONE or NXDOMAIN) when  the domain owner indicates
> that SPF policies always exist.
>
> ·         Ambiguous (clarified):
>
> o   Any message which is neither Authenticated nor Repudiated.  This
> includes any authorized messages which have been processed through a
> mailing list.
>
Doug Foster
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to