The previous message laid out what we should seek in an NP test, but rushed through the ending.
We are looking to create a test: - Which identifies all names that are used for RFC5322.From addressing, so that names which are not identified can be classified as NP=TRUE because the domain owner has never authorized the name for use with >From addressing. - Which produces no false positives after domain owners have taken necessary compliance measures - Which requires a minimum of compliance effort by the domain owner - Which minimizes false negatives as much as possible. The universe of all possible domain names can be partitioned as follows: - Names which are used for both SMTP and RFC5322.From. - Names which are used for SMTP only, not for RFC5322.From - Names which are used for RFC5322.From only, not for SMTP - Names which are no used at all for email. Names used for both SMTP and From For the first group, assume that this occurs because some outbound messages have the same domain for RFC5321.MailFrom and RFC5322.From. How do we detect names used for RFC5321.MailFrom? - SPF is the first indicator, because SPF explicitly affirms that the domain name is used as a MailFrom address. - MX is a secondary indicator, because it explicitly affirms that the domain name accepts mail. - A/AAAA does not explicitly affirm anything about mail usage, but it may be used for mail without being explicitly identified. Treating A/AAAA as equivalent to MX will cause a high number of false negatives, weakening the effectiveness of the NP test. So we need to evaluate whether its inclusion is necessary. Names used for SMTP only We currently have no way to detect domain names that are only used for SMTP. Unless we add an indicator for this purpose, we are forced to assume that all SMTP names are also FROM names. This creates some false negatives, but we have said that some false negatives are tolerable even though they are not desirable. Names used for RFC5322.From only In the context of DMARC, names that are not used for SMTP Mail should be protected with a DKIM signature. Additionally, email is the primary use case for DKIM signatures, so the existence of a DKIM public key is at least suggestive that the name is used for email. DNS does not provide a simple way to identify all DKIM signatures on a domain name, so we are limited to checking only those names that are found within DKIM signatures on the message being evaluated. If a message has a DKIM signatures, and a public key exists in DNS for the specified scope, we can reasonably conclude that the domain owner intends to sign some messages with that signature, and that the most likely domain name for which it will be used is the exact match name. Consequently, the recommended test for this situation is the existence of a DKIM public key which matches a DKIM signature in the message. The NP test is only applicable when the message does not produce DMARC PASS, so the signature itself has tested as unverified, but the presence of the public key indicates that the name is used for email sometimes, even if this particular signature is a forgery. Of course, a message can be DMARC PASS using relaxed alignment on a DKIM signature. This is the reason that an RFC5322.From domain name can be invisible in DNS. To allow any unverified signature key to match any aligned domain name would create too many false negatives. Domain owners will need to take compliance action to ensure that names used only for RFC5322.From are able to comply with the NP test by one of the defined methods. To address this need, it seems appropriate to assume that the existence of an exact-match DMARC policy is also an indicator that the name is used for RFC5322.From messaging. Names which are not used for any email purpose These domain names are identified when all of the other tests have not produced a match, and these produce NP=TRUE as the result. Refining the test: Should A/AAAA be included in the test rule? The NP test is not applicable to all mail, it is only applicable to domains that have published a DMARC policy with an NP clause. Publishing a NP policy, other than NONE, is an assertion that the domain owner has voluntarily undertaken compliance with the NP test. The DMARC policy also suggests that the domain owner has a general interest in making his outbound messages DMARC compliant. The A/AAAA test is needed to avoid false positives only when: - The name is actually used for SMTP mail, and - No SPF record has been published, and - No MX record has been published. For domains that are participating in DMARC, the absence of an SPF record would be surprising, and the absence of both MX and SPF would be even more surprising. Treating an implicit MX as if it was an explicit MX introduces a large number of false positives, significantly weakening the effectiveness of the NP test. I propose that requiring MX or SPF or exact-match DKIM public key or exact-match DMARC policy provides enough options for compliance. The A/AAAA test is not necessary, and is actually counterproductive to the goals of the NP test. On Fri, Dec 17, 2021 at 9:06 PM Scott Kitterman <skl...@kitterman.com> wrote: > On Friday, December 17, 2021 8:43:17 PM EST Tim Wicinski wrote: > > On Fri, Dec 17, 2021 at 6:56 PM Douglas Foster < > > > > dougfoster.emailstanda...@gmail.com> wrote: > > > That is not my position, and I don't know how you drew that > > > conclusion from those words. > > > > Then my mistake. > > > > > I do take the position that DMARC PASS means "This name correctly > > > represents the stated domain", and NP=TRUE means "This name cannot > > > represent the stated domain because the domain owner never uses that > > > name". I am willing to say that if NP=TRUE produces an accurate > result, > > > I > > > will block the message and I can see no reason why anyone else would do > > > otherwise. > > > > > > DMARC FAIL is an ambiguous result, which was your point. DMARC PASS is > > > not ambiguous. NP=TRUE should be ambiguous if at all possible, > otherwise > > > it adds no value. > > > > > > But back to the actual topic: > > > - Do you believe the NP test can be useful? If so, for what purpose? > > > - What is the optimal test to evaluate NP? How did you reach that > > > conclusion? > > > > I see the NP tag being useful for mid to large organizations that have a > > regular amount of organizational change (mergers, acquisitions, etc). > > A large mostly static organization will not deploy the np tag, because "p > > == sp", where the domain tag = the subdomain tag. > > Larger organizations deploying DMARC usually run into the problem of not > > knowing all the mail flows from all the change, and they end up > > with "p != sp" for some period of time. In these cases, np is really > > useful in preventing attack vectors using subdomains (log4j.example.com) > > from > > being used. > > > > I am sure there are folks who track DMARC record changes over time, but > > back in mid 2020 I pulled a bunch of DMARC records of some alexa top 10K, > > and noticed the number of domains where "p != sp". Doing a quick pull of > > those domains and checking now I see a number of them now show "p == sp", > > which means they feel they have a better understanding of their mail > > flows. > > > > I worked for a large organization which had to set "p != sp" for a period > > of time as they understood things better. They are now a "p == sp" > > organization now, which is good. But having the added bonus of blocking > > invalid subdomains during that migration period I am sure would have > > made folks feel better. > > > > (the other use case for the np tag is around TLDs and also the SLDs like > > co.uk, and Scott is all over that). > > Actually .gov.uk. I'd expect that .co.uk has similar challenges to what > we'd > expect with .com. > > What you describe is something that was in my mind when we defined np=, > despite > the focus on PSD at the time. I think that np= has potentially broad > utility > as a gap filler during the deployment process for large organizations. > > I think p=reject will be a problem of a lot of organizations for a long > time, > so I think anything we can do to make it easier to have some set of mail > covered by a reject policy is a good thing. > > Scott K > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
