I am ready to embrace NXDOMAIN as the preferred test, based on two assumptions which I am hoping the group can endorse.
Scope The PSD case is a special case of not-valid-for-mail names, and I was interested in trying to address more than that one case. A complete list seems to be: - Fictitious TLDs - PSD names, because they do not send mail - Unregistered and therefore fictitious organization domains, and their descendants - Fictitious additions to the set of names used for an organization domain - Use of names that are only used for non-mail purposes - Use of names that are used for SMTP but not for RFC5322.From A first question is whether the domain owner is the only arbiter of what names are real or fictitious within his space. This is necessary because DMARC Fail occurs on messages that I want and allow, even though I know that they did not originate from the domain owner. Some US Government web sites and some email security services are important enough to break the rules and get away with it. However, these "acceptable impersonations" are always using an actual email address. Similarly, mailing list messages may produce DMARC Fail, but the subscriber is a valid member of a valid domain. So my first assumption is, "Yes, the domain owner has official control over the definition of valid names within his organization" Not all RFC5322.From domains exist in DNS, and not all DNS names are valid as RFC5322.From domains. "Valid" becomes a nebulous concept based on the intent of the domain owner. While NXDOMAIN is certainly a solution to the PSD problem, it is not obvious that it is a sufficient solution to the general problem. My second assumption is that as an evaluator, I am unlikely to gain any benefit from checking for invalid names underneath an organization domain. If a domain owner ensures that both mail-enabled and non-mail names are protected using SP=REJECT, then an attacker gains no advantage from choosing an invalid name over a valid one. Similarly, if the domain owner leaves both mail-enabled and non-mail names unprotected using SP=NONE, then the attacker has no advantage from choosing an invalid name over a valid one. To the contrary, it seems advantageous for the attacker to use a valid name when one is available. Using an invalid name becomes advantageous only if the domain owner protects all mail-enabled names with P=REJECT, but leaves non-mail names unprotected using SP=NONE. This configuration seems bizarre to me, and therefore unimportant. Nonetheless, it still might be useful if all non-mail names could be determined with confidence, but this requires near-perfect information to be useful, and experience shows that this is unlikely. If the second assumption is accepted, then the last three scope topics disappear. For the remaining three - For unregistered and therefore fictitious organization domains. NXDOMAIN is the simplest and most appropriate test. We block based on NP=REJECT in the PSD's DMARC policy when a TXT (or any) name lookup returns NXDOMAIN. Organizations within that PSD can avoid false positives easily: either publish their own DMARC policy without NP=REJECT, or ensure that all of their RFC5322.From domains do exist in DNS, even if the entry is as trivial as Type=TXT, DATA="I Exist". - For PSDs, we block if the PSD has a DMARC record with the PSD flag. If that test is considered insufficient, we block by consulting the publicsuffix.org list and block names from that list that the evaluator considers applicable. - For fictitious TLDS, we have an undiscussed topic. If all valid TLDs now participate in DNS SEC, then a DNS lookup on valid TLDs will return DATA or NOERROR, while fictitious TLDS will always return NXDOMAIN. If the PSD flag becomes ubiquitous, then a tree walk which does not produce a DMARC policy could also be evidence of an invalid TLD. If PSD Flag usage is not universal, then a DNS query on the TLD name should be used as a follow-up to the tree walk. If some valid TLDs do not participate in DNS SEC and do not publish the PSD flag, then we are back to consulting a list. Doug On Wed, Dec 22, 2021 at 2:29 AM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Tue, Dec 21, 2021 at 11:32 AM John Levine <jo...@taugh.com> wrote: > >> The DNS has had a formal definition of non-existence for over 30 >> years. You look up a name, if it returns records or NOERROR it exists, >> if it returns NXDOMAIN it doesn't. There is no reason for us to invent >> something new and incompatible. >> >> >I don't remember exactly why we settled on A/ AAAA/ MX, but the lack of >> a clear, actionable definition is why we included one. >> >> See above. I don't remember where the text in A.4 came from, but it is >> wrong. >> If we are telling people to test whether a domain exists, they should do >> it >> the way the DNS does it. The correct test happens to be cheaper than A.4, >> one query rather than three. >> > > We're talking about two different things here, I think. The DNS > definition of "nonexistent" is as cited above while the DMARC definition > matches the well established SMTP algorithm that figures out where the next > hop for a particular recipient is. If there is no next hop, then for email > purposes, the domain doesn't "exist". The logic goes something like: If > this message fails DMARC, and a bounce has nowhere to go, then I'm pretty > sure I don't want to deliver it. > > We're free to change our minds about what test is appropriate here, but > that was the genesis of A.4. > > -MSK > _______________________________________________ > 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
