On Tue, Apr 6, 2021 at 4:54 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> If the SPF Policy lookup returns NXDOMAIN, then we are at a full stop with > all the information needed to make a decision. (The sender is violating > ICANN name registration policies). Ignoring NXDOMAIN and continuing to > look for MX/A/AAAA is a waste of information and a waste of resources. > I agree. But clearly, the norm in this group is to check MX/A/AAA because it seems > likely to be a more powerful filter. I wonder if that is actually true. > In the context of the code doing the SPF evaluation, I don't think it is. If TXT returns NXDOMAIN for a name, so will any other type. That's the definition of NXDOMAIN; there are no data of any type for this name. See also RFC 8020. Fortunately, a properly functioning local nameserver will cache the answer and just repeat it when subsequent MX, A, or AAAA queries get issued, so the waste is relatively cheap. I imagine some DNS APIs are ambiguous (i.e., lazy) about reporting "That name does not exist (rcode=NXDOMAIN)" differently from "That name exists, but there's no record of the type you requested (rcode=NOERROR, ancount=0)", which can result in some wasted time, but I expect the end result would be the same. 1) A/AAAA is a pretty weak test, since many domains have A/AAAA records on > the domain name for web purposes. > Independently of SPF, it's not a weak test since the standards allow exactly this kind of setup for a domain that wants to receive mail. Again, Section 5.1 of RFC 5321. I do respond to SPF NONE by applying a best-guess SPF policy which includes > MX and A, and sometimes produces SPF PASS. But I no longer do that for > non-existent domains. > "Best guess SPF" is discouraged. See http://www.open-spf.org/FAQ/Best_guess_record/. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
