Anyway, I would make -mxlocalcheck default to 1 if you're doing -mxcheck. And I would add a check for 192.168.xxx.xxx to that also. Just knowing whether there is an MX record in the DNS doesn't tell you much by itself. You want to know whether it is likely that mail can be delivered. The extra check make the result more reliable and should therefore be done by default.

Liz

For those unhappy with Email::Valid I'd consider Mail::CheckUser as an alternative. Lots more options and works very well in my experience. It includes domain checks (amongst many others.)

Oh, and please add the other private address ranges also (RFC1918 - Address Allocation for Private Internets). The same logic applies to all four ranges - these are local addresses not usable for Internet addressing.
• 10.0.0.0       - 10.255.255.255 (10/8 prefix)
• 172.16.0.0   - 172.31.255.255 (172.16/12 prefix)
• 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
• 127.     (local loopback)
Of course an extension of that idea would be to identify all the other ranges that are marked as unassigned or dubious, like 224. or 14. or 240. and so on.   INTERNET PROTOCOL V4 ADDRESS SPACE and RFC3330 - Special-Use IPv4 Addresses might be a start here.

I know our local email admin hates the _obvious_ MX obfuscation that spammers employ...

Of course an extension of that idea would be to identify all the other ranges that are marked as unassigned or dubious, like 224. or 14. or 240. and so on. INTERNET PROTOCOL V4 ADDRESS SPACE and RFC3330 - Special-Use IPv4 Addresses might be a start here.

That's fairly complex, and prone to require a lot of updating as ranges are reassigned. It would be simpler to rely on an extant mechanism, such as DNS. For example, require the IP address of the sending mail server to be reverse-lookupable (PTR record in in-addr.arpa). Of course, then you'll be blocking mail from pretty much 100% of Asia... however, it would be possible to combine this with other techniques -- for example, if the IP of the sending mailserver _isn't_ reversable, check it against a whitelist, and if it's not there greylist and tempfail it for N minutes, or apply heuristics, or whatever.

Of course, all of that has pretty much nothing to do with the email address in the From field, which can generally be considered worthless for such purposes.

If you're checking an email address that someone used to sign up for some service, just require them to respond to a confirmation message. That positively guarantees the address is valid.

---

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

I would make -mxlocalcheck default to 1 if you're doing -mxcheck.

That would be my personal preference, but the author of Email::Valid asked me to write the patch so that it did not change any of the behavior of any existing code. This, also, is a very valid desire.

-- Eric Hammond