in reply to Re: Email::Valid appears to disqualify valid email addresses
in thread Email::Valid appears to disqualify valid email addresses

Funny, I just submitted patches for -tldcheck, which uses Net::Domain::TLD to check whether the top level domain of an email address is valid.

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

  • Comment on Re: Re: Email::Valid appears to disqualify valid email addresses

Replies are listed 'Best First'.
Re^3: Email::Valid appears to disqualify valid email addresses
by adrianh (Chancellor) on Aug 21, 2003 at 13:41 UTC

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

[reply]
Re: Re: Re: Email::Valid appears to disqualify valid email addresses
by shenme (Priest) on Aug 22, 2003 at 06:15 UTC
    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...

[reply]
      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]
[reply]
[d/l]
Re: Re: Re: Email::Valid appears to disqualify valid email addresses
by esh (Pilgrim) on Aug 21, 2003 at 18:50 UTC

    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

[reply]

In Section Seekers of Perl Wisdom