princepawn has asked for the wisdom of the Perl Monks concerning the following question:

To my surprise, an valid email address preceding the @ becomes disqualifiied by Email::Valid when a . is appended to it. Why would that make an email invalid?

code

use Email::Valid;
use strict;

sub check {

    my $o = shift;
    my $address = shift;

    print "email $address is ";
    print ($o->address($address) ? '' : 'not');
    print " valid\n";


}

my @address = qw(

         jim@mail.com
         jim.@mail.com
         jim.beam@mail.com
         .jim@mail.com
         jim-@mail.com
         -jim@mail.com

);

my $ev = Email::Valid->new;

check ($ev,$_) for @address;

[download]

results


[tbone@horse1 email-valid]$ perl ev.pl
email jim@mail.com is  valid
email jim.@mail.com is not valid
email jim.beam@mail.com is  valid
email .jim@mail.com is not valid
email jim-@mail.com is  valid
email -jim@mail.com is not valid
[tbone@horse1 email-valid]$

[download]
<address></address> Last modified: Wed Aug 20 15:43:59 PDT 2003 </body> </html>

Replies are listed 'Best First'.
Re: Email::Valid appears to disqualify valid email addresses
by belg4mit (Prior) on Aug 20, 2003 at 23:56 UTC
    Did you read the RFC? 
         address     =  mailbox                      ; one addressee
                 /  group                        ; named list
...
     mailbox     =  addr-spec                    ; simple address
                 /  phrase route-addr            ; name & addr-spec
...
     addr-spec   =  local-part "@" domain        ; global address

     local-part  =  word *("." word)             ; uninterpreted      
+                                           ; case-preserve

    [download]
    Those *aren't* valid email addresses. There may be mail clients and servers which allow them, but they aren't valid.

    --
    I'm not belgian but I play one on TV.

[reply]
[d/l]
      RFC 822 has been obsoleted by its successor, RFC 2822.

      But, as I see it, your point still stands.

[reply]
Re: Email::Valid appears to disqualify valid email addresses
by jmcnamara (Monsignor) on Aug 21, 2003 at 00:07 UTC

    Those email addresses aren't valid although they are still used sometimes. As such Tatsuhiko Miyagawa's Email::Valid::Loose accepts some of them with the following rationale:
    Email::Valid::Loose is a subclass of Email::Valid, which allows . (dot) before @ (at-mark). It is invalid in RFC822, but is commonly used in some of mobile phone addresses in Japan (like docomo.ne.jp or jp-t.ne.jp).

    --
    John.

[reply]
Re: Email::Valid appears to disqualify valid email addresses
by esh (Pilgrim) on Aug 21, 2003 at 06:56 UTC

    Looks like your question has been answered, so I'll toss in a loosly related plug for a patch I wrote to Email::Valid which was supposed to make it in to the distribution, but the author has not gotten around to it yet.

    One of the checks Email::Valid supports is to make sure that a domain has an MX record. In practice, I've found a lot of domains that have MX records which point to 127.0.0.1 (localhost). This is an obvious clue that the domain does not wish to be emailed and I thought that Email::Valid should pay attention to this and disallow email addresses at these domains.

    The patch (for source, unit tests, and documentation) is here: http://www.anvilon.com/software/download/Email::Valid-mxlocalcheck.patch

    The patch does not modify the normal behavior; you have to specifically ask for the localhost blocking mechanism check using a new option (mxlocalcheck).

    -- Eric Hammond

[reply]
      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

[reply]

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

        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]
Re: Email::Valid appears to disqualify valid email addresses
by dtr (Scribe) on Aug 21, 2003 at 11:59 UTC

    A quick test on Sendmail and Exchange shows that MAIL FROM: "jim."@mail.com will actually work fine.

[reply]
[d/l]
      Eh, yeah, but those quotes are significant. "jim." is not the same as jim.. For about the same reason that in Perl "3 + 4" and 3 + 4 aren't the same either.

      Abigail

[reply]

Back to Seekers of Perl Wisdom