Please forgive my typo. I meant to say that I am currently testing RFC5321.MailFrom (only).
(I am not doing evaluating any non-standard SPF algorithms.) On Mon, Apr 5, 2021, 5:46 PM Todd Herr <[email protected]> wrote: > On Mon, Apr 5, 2021 at 5:02 PM Douglas Foster < > [email protected]> 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:* [email protected] > *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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
