Re: [dmarc-ietf] NXDOMAIN

[Laura Atkins <[e-mail]>]

> On 5 Apr 2021, at 22:46, Todd Herr <todd.herr=[e-mail]> wrote:
> 
> On Mon, Apr 5, 2021 at 5:02 PM Douglas Foster <[e-mail] <mailto:[e-mail]>> 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.

There is a huge amount of dis- and mis-information about SPF for the 5322.from domain. Many, and I mean an embarrassingly high number of ‘many’, ESPs actually suggest that their customers publish include: _spf.espdomain.example in their 5322.from domain TXT record. This eventually causes operational issues due to more than 10 DNS lookups. 

Some of this was done because the ESP folks don't understand the SPF spec. But some of this was done because a large ISP decided to check SPF records on the 5322.from domain and delivery would suffer if there was no SPF. 

Misapplying SPF to the 5322.from is a bad idea and only compounds mistakes of the past. 

> 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. 

I agree with the sentiment here. Lack of any SPF record, particularly for small and non-bulk mail, simply means someone stood up a mailserver (or started using a service) without fully setting it up. That could be a mistake, or intentional, or malicious and experience tells us all of those are possible. Contrast that with a +all record, where experience tells us that is usually malicious. I actually found a +all in the wild in the past few weeks. It was in the process of investigating a client’s customer due to suspected spam. The +all was yet more confirmation that the customer was a spammer (as if the swedish hashbusting text and CAN SPAM violations weren’t enough). 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[e-mail]
[phone]		

Email Delivery Blog: https://wordtothewise.com/blog