RFC 9091 provides a way to detect misuse of unregistered organizations, one
level below the PSD/Registrar level.   Use of an unregistered name is
inherently a form of unauthorized impersonation.   Consequently, the test
may be used whether the PSD has published a policy or not, and the default
can reasonably be set to reject on non-existence.  Every PSD policy should
have a NP policy, but if it is omitted, I have a hard time justifying why
the SP policy should be used in its place.

For unregistered organizations, the NP test will produce the same result
whether the RFC5322.From address or the PSD+1 organization name is used,
but when it is applied to registered organizatios, the choice matters.

When an organization is properly registered, only the domain owner decides
whether  RFC5322.From addresses with non-existent domains may be used.
 Absence of a DMARC policy does not transfer that right to the PSD or
registrar.  To properly limit the scope of the NP clause on a PSD policy,
the non-existence test for PSD=Y policies should be based on the PSD+1
organization name only.

Within a registered organization, use of a non-existent RFC5322.From
address is not inherently suspicious and is not uncommon.  Non-existent
subdomains will currently authenticate for DMARC using using relaxed
alignment.   However, a domain owner may wish to use his DMARC policy to
announce that he never uses non-existent names within his subtree.  This is
done by publishing a NP policy.  When this is the case, the non-existent
test is applied to the RFC5322.From domain name.  When a DMARC policy is
found but the NP term is omitted, all subdomains are handled equally, and
the SP term applies.

So we have a double error:   We fail to distinguish between the two types
of tests, and we fail to distinguish between the two different default
conditions, and we have not provided upward compatibility with RFC 9091.

DF
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to