SPF check seems wrong

[ThiefMaster]

v=spf1 -all means the domain does not send email. However, it contains absolutely no information about whether the domain receives email.

And in fact, if the domain has an MX record I'd completely expect it to receive email just fine. So checking SPF even after finding a valid MX seems questionable as well.

I suggest adding an option to disable the SPF check.

[JoshData]

I'd be more convinced if you can find an example in the wild of a domain that would be incorrectly rejected by the library.

[ThiefMaster]

I think it's very unlikely to find a domain that has reject-all SPF records but accepts emails. However, SPF does not make any statement about being able to receive emails, so I think it's not a good idea to use it for this purpose

[JoshData]

If it's so unlikely that it does not occur, then it doesn't matter what we do. If it's likely enough to occur, then we can have an informed conversation looking at actual examples.

I have a list of 400 domains so far that fail because of the SPF check. One interesting one is mailinator.com:

mailinator.com.		300	IN	MX	1 mail2.mailinator.com.
mailinator.com.		300	IN	MX	1 mail.mailinator.com.
mailinator.com.		300	IN	TXT	"v=spf1 -all"

mailinator is a developer tool for testing outbound emails to throw-away domains.

All of the other cases I checked seemed like defunct organizations.

[ThiefMaster]

I'd say that mailinator failing this check is exactly why this should be configurable!

I don't care if someone uses a mailinator address or a proper one. But what I do care is that I can send an email to the address the user gave me...

If you want to blacklist throwaway providers fine, but that's a different feature and beyond merely validating an email address!

PS: I don't use mailinator as a dev tool. I use it to avoid giving a real email to sites which ask for one but shouldn't (e.g. to download something).

[JoshData]

I get your point.

What I'm thinking to do is to move the check so that it's only applied if there is no MX record. Mail can be delivered if there's no MX record if there is an A record, and the library permits that, but these are likely to be domains that are not really handling email. I think if someone sets up a SPF reject-all record and doesn't set up an MX record, it would be very unlikely that the domain is actually used for email.

In my database of domains that are rejected by the new SPF check, about half have MX records (like mailinator). So making this change would pass validation on that half of the domains that were newly rejected and fail validation for the other half.

[ThiefMaster]

Yes, I think checking it only if there is no MX is much better.

(i'd still prefer a way to disable it altogether, but skipping the check if there is a MX would be enough for me)