Allow user@example or user@localhost in email validation?

Question

I'm working on an email validation check and we need to decided whether to allow user@localhost and user@example (notice no .anything) to be validated as a valid email address. This is for an open source project that has a number of use cases on both the web at large and intranets.

RFC 2822 (Internet Message Format Standard) allows it but RFC 2821 (SMTP Standard) says it should fail.

Thoughts?

Answer 1

It depends on your application. If you think that several of your users will have an email @localhost, and you don't mind. Then go for it.

Answer 2

Make it a configurable option, so people can decide for themselves. I'd default it to failure, personally, as I've yet to run into a case - intranet or public internet - where I've had someone use a valid user@localhost type address.

Answer 3

Well, if you have DNS working for internally you could always just do a DNS lookup.

But if this is going to fail with SMTP, then I would suggest making sure you don't include it.

Answer 4

I have seen email addresses of the form user@localhost, typically when looking at archives of a mailing list and the administrator hosted and posted from the same machine. So it can definitely occur - and I admit it broke my parsing routine! So now I am a little more flexible to email addresses.

Answer 5

Looking at this it looks like you've we need two quick checks as detailed:

<?php 
function valid_email($email) { 
    // First, we check that there's one @ symbol, and that the lengths are right 
    if (!ereg("^[^@]{1,64}@[^@]{1,255}$", $email)) { 
     // Email invalid because wrong number of characters in one section, or wrong number of @ symbols.
     return false; 
    }

    // take a given email address and split it into the username and domain. 
    list($userName, $mailDomain) = split("@", $email); 
    if (checkdnsrr($mailDomain, "MX")) { 
     // this is a valid email domain! 
     return true;
    } 
    else { 
     // this email domain doesn't exist!
     return false;
    }
} 
?>

(source 1, source 2)

Answer 6

I would disable it. Very few organizations use internal domains, and those that do generally use "acme.localhost" or "intranet.com" or something else of the like. There is some sort of configuration going on in the DNS that they use to make it work.

Regardless, internal email is nearly dead anyway: with the advent of instant messaging, Twitter, and SMS along with the increasing availability of external email for every member of a company, it is almost entirely likely that you will never get a TLD-less domain in an email.

For the folks that do require it, they can always tweak the regex themselves, as they were savvy enough to set up a custom hostname to handle internal email.