in reply to Re^2: Practical e-mail address validation (flex)
in thread Practical e-mail address validation

tye,
It has been 6 years since I worked at the US Dept. Of Justice and had the RFCs memorized but you can see that others agree with me. Neither Email::Valid nor Email::Address believe 'foo.@bar.com' is a valid email address and Email::Valid::Loose only exists to relax the rules of RFC 2822 to allow a period before the at.

Regarding case sensitivity in the user portion, you did make your position clear. In fact, I indicated you had already mentioned it. I brought it up again because I believe it would be a valuable rule to turn on/off if they were using this theoretical module to identify spammers.

The reason I suggest such a pick and choose module is thus: The specific reasons for wanting to look for email addresses and then choose to deem them invalid changes from situation to situation. Most folks are completely ignorant of the RFCs and it would be easy for them to say "in my situation, I want to allow X and Y but deny Z" without having to go look anything up.

Cheers - L~R

  • Comment on Re^3: Practical e-mail address validation (flex)

Replies are listed 'Best First'.
Re^4: Practical e-mail address validation (flexes)
by tye (Sage) on Sep 13, 2008 at 18:20 UTC

    You appear to mean "directly before the @". Thanks for the clarification. Email::Valid::Loose further clarifies:

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

    So the items identified so far:

    • Allow /\.\@/
    • Disallow /\@.*%/ (actually more, since you answered my question in the negative in a private /msg and promised more details later)
    • Disallow CFWS w/in the address
    • Require /\@.*\./
    • Require /\.[a-zA-Z]{2,}$/
    • Require RFC1035-compliant domain (except empty ones)
    • Extend RFC1035 to allow domain labels that start with a digit
    • Disallow quoting (usually of $local_part)
    • Disallow escaping (usually of $local_part)
    • Disallow /\+.*\@/
    • Disallow "group"s (/$display_name:$mailbox_list;/)
    • Disallow "name-addr" (/$display_name?$angle_addr/)
    • Disallow "obs*" (obs-angle-addr, obs-mbox-list, obs-addr-list, obs-local-part, obs-domain)

    - tye        

[reply]
[d/l]
[select]
      tye,
      They (email addresses with periods immediately preceding the @) were also very common by Microsoft Exchange back when I was working at the DoJ. I am not sure if M$ has become more compliant. I am going to be updating this node with a variety of other ways at attempting to exploit open relays and I will /msg you when complete.

      Update: Rather than enumerate them myself, go to http://www.abuse.net/relay.html and test an MTA you believe to be secure. It shows you all the email addresses it uses to test with (from and to). I also realized I had the relay syntax wrong. It is foo%bar.com@example.com. I have updated the prior node.

      Update: I haven't provided a complete list of "rules" that I think such a theoretical module should include but having "John Smith"@example.com is another one that should be flexible. If I come up with more I will add them here but it has been a long time since I thought about such things. Oh, and I used to have to worry about non-SMTP addresses too like CC:Mail and GroupWise (fortunately not UUCP).

      Cheers - L~R

[reply]
[d/l]

In Section Cool Uses for Perl