On Mon, Apr 5, 2021 at 5:02 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> As a result of earlier discussions, I have been investigating NXDOMAIN as > an email filtering criteria. > > One question from those discussions was the best way to detect NXDOMAIN. > I realized that I needed a query which specifically returns NXDOMAIN as a > result, not simply the absence of a particular result. Additionally, a > lookup on A/AAAA with results could represent either a domain name with no > host segment, or a host segment and a parent domain.. Consequently, the > best test seems to query for type=TXT, match=domainname. > > I have applied this rule to incoming RFC5322.MailFrom addresses and found > the test to be useful. For my mail stream, 20% of the messages with > SPF=NONE have this result because of NXDOMAIN. The percentages were > roughly equal whether evaluating unique domain names or unique messages. > > While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is > probably unwanted, NXDOMAIN has a higher probability of being unwanted. > > I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but > hope to get that done in the weeks ahead. > > Is anyone else collecting data on NXDOMAIN, and able to share experience? > I can share experience... Several jobs ago, when I was in position to set anti-spam policy for a mid-sized US-based cable ISP, if the RFC5321.From or RFC5322.From domain lacked both an MX record and an A/AAAA record, that was enough for me to reject the mail on the grounds that I was unwilling to accept anything to which the recipient could not reply. I don't recall any complaints from my side of the transaction. I'm not sure I'd make the same decision based on the lack of an SPF record, especially for the RFC5322.From domain, since SPF is keyed to the RFC5321.From domain (or the EHLO name), and so I have no expectations that an SPF record will exist for the RFC5322.From domain. Even a lack of SPF for the RFC5321.From domain doesn't, for me, automatically rule out a message. I'd be more inclined to reject mail where the SPF record ended in "+all" than I would where there was no SPF record, because "+all" lands differently for me than does "no SPF record published". Both say that the domain owner doesn't care about SPF, but "+all" strikes me as overt disregard for SPF, while a lack of a record might just signal less hostility. Lack of an SPF record eliminates one possible path to a DMARC pass verdict, and a DMARC pass verdict allows me to treat the mail as authentic, and therefore worthy of treatment earned by previous authentic messages for the DMARC domain, which could be good or bad, depending on the history. Authenticated mail is not necessarily wanted mail; it's just mail for which I can be reasonably sure of the identity of the responsible party, and if that responsible party has a history of sending unwanted mail, then I can treat its authenticated mail as unwanted. If I can't determine if the mail is authentic, then I will treat it no better than, and perhaps worse than, the treatment earned by previous authentic messages for the DMARC domain, assuming any previous authentic messages exist. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
