30-seconds-of-code: [BUG]validateEmail is wrong

Created on 21 Dec 2017  路  7Comments  路  Source: 30-seconds/30-seconds-of-code



[BUG] validateEmail does not follow the spec.

Expected Snippet Behavior

https://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx/

Current Snippet Behavior

"me@"@y-less.com - apparently invalid, but should be valid (quoted prefixes).
[email protected] - apparently valid, but should be invalid (not an IP).
me@y-less.褉褎 - apparently invalid, but should be valid (any internationalised domain).

Possible Solution

Just don't try! The ONLY correct way to validate an e-mail is to send a test e-mail. I've seen page-long regexes designed to correctly verify all the parts, and that STILL doesn't guarantee that the result actually exists.

bug discussion good first issue help wanted opinions needed

All 7 comments

We could also possibly add a disclaimer that this is a basic check and not production-ready if we don't want to remove. Opinions/suggestions/fixes?

We could also possibly add a disclaimer that this is a basic check and not production-ready

It's not really a basic check. It's a broken check. Better to just remove it. Too much time has already been lost by developers trying to validate email addresses and it creates a bad user experience when you try to enter a valid working email address into a website only to have it rejected by the javascript as invalid.

The only real way to "validate" and email has been stated: See if you get a response from any server. In my work we decided to do a simple check to just make sure it "mostly" conformed: check for an @ symbol that is not at the start or end of the string. If it failed we noted it and moved on. It is literally to costly to try and validate every email. The RFC is huge. IPs are valid, unicode is valid, blah blah blah, edge case after edge case. It just can't be done because of them.

Attempting to do something like this has been seen as a fools folly in EVERY industry, just like validating a mailing address, for the exact same reason.

An updated description would set a precedence of this library only needing code that is "good enough" and we have plenty of better examples of regex in the library. This one is long, hard to understand, and is actually a valid topic for a graduate level CS thesis.

Vote to remove as well due to size of RFC and the difficulty of implementing it with every edge case.

@Y-Less isn't

[email protected]

invalid because the RFC states IP direct addresses need to be surrounded by brackets( [ & ] )?

I'm not sure on that (I don't think so, but might be wrong) - I was just pointing out that 999 (and 270) is not a valid IP component, but is still accepted as-is.

@skatcat31 Your argument and explanation is compelling enough to convince me (after reading a bit about mail validation and some opinions around here). I, too, vote to remove the snippet.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for any follow-up tasks.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Bruce-Feldman picture Bruce-Feldman  路  4Comments

konglx90 picture konglx90  路  6Comments

fuchao2012 picture fuchao2012  路  4Comments

emelendez picture emelendez  路  4Comments

henrycjchen picture henrycjchen  路  4Comments