This is a useful point for discussion. MX checks are a valid tool for assessing SMTP MailFrom addresses, since the sender is supposed to be ready to accept non-delivery reports and other automated messages. Of course, this has applicability if (but only if) the RFC5322.From domain is the same as the RFC5321.MailFrom domain. As far as I know, DMARC is the only established tool for evaluating the RFC5322.From address when it differs from the RFC5321.MailFrom address. So to my thinking, the NP test is new territory without precedent.
I am looking for a test that says decisively, "The domain owner has never authorized the use of this name for any mail-related purposes." There are many reasons why an acceptable message may fail DMARC verification. One of those reasons is that the message is an impersonation, but the impersonation is acceptable, typically because it is sent for the benefit of an account user. But acceptable messages will always use a domain name that is already in use by the domain owner, never one that they invented. The use of a never-authorized name will always be an unacceptable form of impersonation, and should be blocked. I thought that the whole WG had consensus on this point. The question then becomes, "How do we construct a decisive test?" We need a test that has very little possibility of a false positive that would cause a message to be blocked. My primary target is the educational segment, where everyone assumes that they will always use P/SP=NONE. because they never want their legitimate messages, including mailing list messages to be blocked. They should be willing to use NP=Reject if they are confident that NP will never block a legitimate message. A weak algorithm is acceptable if it blocks some but not all messages from never-used domains; false negatives are undesirable but tolerable. A result of DMARC FAIL with NP=FALSE will leave the evaluator in the same risk posture as if the NP test had not been performed. The only method we have for evaluating NP is the DNS, so the weakest possible rule is to block on NXDOMAIN. Unfortunately, even that test returns false positives. They occurs when messages sent by email service providers use the provider's SMTP address, and this is the norm. For these mailings, the only constraints on the RFC5322.From address are the ones imposed by the provider (you will not impersonate my other clients) and by the client itself (via DMARC). With relaxed alignment, the client can invent and use domain names that are not in DNS. Consequently, any NP test will likely require a participating organization to implement some compliance measures, such as creating DNS entries for those that do not exist at present. Those measures should be as simple and error-free as possible, or the risk-averse organization will simply not participate. To implement the NP tests, we devise DNS queries which indicate that the name exists. When a DATA result is not obtained by any of those queries, we return NP=TRUE. To minimize false positives, we want to use an expansive set of DNS queries. MX+A+AAAA gives one set of in-use names. Adding SPF will add another set of in-use names. Adding exact-match DMARC and DKIM will add another set of in-use names. The only reason to omit these tests is if you can demonstrate that one of them is always superfluous because it will only include names obtained from other sources, or because it misleads. A+AAAA may belong because it adds to the inclusive list, but it weakens the rule a lot. So I ask whether an acceptable result can be produced without it, a direct challenge to my previous sentence. This is a tricky one, and best left for another stage in the analysis. Doug On Fri, Dec 17, 2021 at 7:01 PM Scott Kitterman <[email protected]> wrote: > > > On December 17, 2021 11:26:38 PM UTC, Douglas Foster < > [email protected]> wrote: > .. > >A year after raising my concerns, I am still trying to get a collaborative > >discussion started about what the optimal test looks like. In a > >collaborative discussion, those who are happy with the status quo convince > >the skeptics to come on board, listen to their concerns, acknowledge them, > >and do what they can to accommodate those concerns so that consensus can > be > >achieved. I am willing to be convinced, but I am skeptical and I am > >looking for some collaboration. > > > It may be that this is a cultural issue then. In the IETF, where there is > an established consensus (rough or not), the burden is on those seeking to > overturn the consensus to convince people. If you think about it, if a > working group were obligated to rehash things whenever new people show up, > it would be difficult to accomplish anything in an open environment where > new people can show up anytime. > > I suspect you might have more luck if you first consulted Chesterton's > Fence. I think you'd have more luck with questions about why things are > the way they are than immediate assertions that they are wrong. > > Scott K > > P.S. At least as I understand it. I'm relatively new too. > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
