Failing email strings

[thanpolas]

I used to have the following valid emails in my test suite, validator.isEmail() will reject them:

var validEmails = [
  '"Abc\\@def"@example.com',
  '"Fred Bloggs"@example.com',
  '"Joe\\Blow"@example.com',
  '"Abc@def"@example.com',
];

I know they look weird, but they are valid email addresses.

[thanpolas]

These non valid emails will pass as valid:

var notValid = [
  '[email protected]',
  '[email protected]',
  'a-very-long-email-over-161-chars@ratar.lorem.ipsum.rata.lorem.ipsum.rata.' +
    'lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.' +
    'lorem.ipsum.rata.com'
];

[chriso]

I can't seem to find any references to a double quote being allowed in email addresses. Do you have a link to a relevant RFC? From the stackoverflow and wikipedia articles I've found it doesn't look like it's allowed. Do the RFC's include a length restriction?

As for the invalid TLDs that are passing, it doesn't currently check whether the TLD is valid or not. The list of TLDs would bulk up the size a fair bit and the new custom TLDs will land soon so there's not much point including them.

I might make a note in the README saying that you should also check whether the domain has an MX record, etc. as an extra validation step.

[thanpolas]

I was surprised to find that these are valid emails too.

You can verify with multiple ways, i just do a telnet to an smtp server and check the responses on the RCPT TO: command. You can use http://isemail.info/ which performs the same over web.

For the wrongfully passing emails, the first sample using a single char as TLD is an easy reject.

I used to have a regex multiplier rule of {2,3} for the TLD but after checking the TLD list at wikipedia things are a bit more hairy... I'd never suggest including all the TLDs.... SMTPs seem to accept any email address regardless of TLD, which is understandable (avoiding a DNS query). So that's on you to decide how to handle.

I also found that the max allowed size for an email is:

the upper limit on address lengths should normally be considered to be 256

Source: http://www.rfc-editor.org/errata_search.php?rfc=3696&eid=1690

[markstos]

For rigorous battle-tested email validation used by a high-volume email host, see Perl's Email::Valid, with the "Source" link here:

https://metacpan.org/pod/Email::Valid

While crazy-long RFC-standard Regex usually isn't wasn't you want, the details how the username and domain parts are validated may be of interest. The rules end up being surprisingly loose to accommodate all the valid edge cases.

Fully RFC-compliant email validation would likely include cases you don't want, like allow bare usernames (for local area email), or using IP addresses instead of domain names.

[joe-mojo]

@chriso : http://en.wikipedia.org/wiki/Email_address

[ItalyPaleAle]

While developing some tests, I found that also this email address (part of the validator.normalizeEmail test cases) fails the validator.isEmail test:
[email protected]

Apparently, it's double/triple dots that make it fail.

Also, with the new gTLDs, maybe you should support also emails like "user@hostname"? (e.g. "admin@google")

[ipeisong]

I also tested on this:
[email protected]
this is valid as well.
not so nice ...

[chriso]

Email validation is hard. PRs are always welcome :)

[joe-mojo]

http://www.regular-expressions.info/email.html

Be ready to freak out.

Le 10 déc. 2014 à 04:30, chriso [email protected] a écrit :

Email validation is hard. PRs are always welcome :)

—
Reply to this email directly or view it on GitHub.

[markstos]

@ipeisong: [email protected] is a valid email address according to RFC 822. You can check it against the RFC here:

http://sphinx.mythic-beasts.com/~pdw/cgi-bin/emailvalidate?address=asdf@asdf.com.asd.fasd.f.asdf.asd.fa.xn--sdf-x68do18h

[andyskw]

It seems so, that validator.isEmail() will reject e-mails without TLD-s as well, but they should also pass - according to the RFC.

It may be a design decision as well, but in this case it would be nice to mention in the README, since browsers started allowing them with <input type="email" /> (probably earlier, just found it in Chrome).

Update: Meanwhile require_tld: true option will come to the rescue, as it is supported by isEmail().

[chriso]

@andyskw you can use validator.isEmail(email_str, {require_tld: false});

[chriso]

@thanpolas the emails you gave as examples now validate correctly:

> validator.isEmail('"Abc\\@def"@example.com')
true
> validator.isEmail('"Fred Bloggs"@example.com')
true
> validator.isEmail('"Joe\\Blow"@example.com')
true
> validator.isEmail('"Abc@def"@example.com')
true
> validator.isEmail('[email protected]')
false

The remaining two that validate incorrectly are:

> validator.isEmail('[email protected]')
true
> validator.isEmail('a-very-long-email-over-161-chars@ratar.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.com')
true

Some thoughts:

• [email protected]: As mentioned above: with the onset of gTLDs, validating the TLD part is outside the scope of the library. .comm may be valid now or in the future.
• a-very-long-email-over-161-chars@ratar.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.lorem.ipsum.rata.com: Can you point to an RFC where length is mentioned? I can fix this one if so.

[thanpolas]

Yey! Thank you @chriso!

Re length:

the upper limit on address lengths should normally be considered to be 256

Source: http://www.rfc-editor.org/errata_search.php?rfc=3696&eid=1690

[ASafaeirad]

Is it ok?

> validator.isEmail("[email protected]");
false

[email protected]

[tux-tn]

@frontendmonster [email protected] is not a valid gmail address.
Only letters, numbers and dots are authorized in gmail

[joe-mojo]

@tux-tn @frontendmonster You forgot '+'. The + character is totally valid in gmail address.

[tux-tn]

it's a special character for sub addresses and yes it's a valid character in validator.js