If you really want to do some clientside validation, just keep a basic regex and warn the user if the address doesn't seem right.. Or use MailCheck[1].
0. http://davidcel.is/blog/2012/09/06/stop-validating-email-add...
11–20 of 65 posts
If you really want to do some clientside validation, just keep a basic regex and warn the user if the address doesn't seem right.. Or use MailCheck[1].
0. http://davidcel.is/blog/2012/09/06/stop-validating-email-add...
I believe this falls under the category of "things that may be fun to play around with but should never be used in a real system". Unfortunately, I bet there are thousands of "real systems" employing regexes like this... How many problems does this solve? Probably zero. How many does (/will) it cause? Probably much more than zero.
Case in point, at work the other day I found a bug in a service I manage. It consists of a front end form (built by one team), which submits data to another system (built by my team), which then passes the data to a third party. The third party was rejecting the data we were trying to send them as the email addresses were apparently invalid. The validation they were doing didn't match the validation the front end form did, so to the user everything seemed fine.
I simply don't validate emails up front anymore. The only thing I check for is if the string contains an @-char, I only do that to be nice if it's left out by accident. Instead of having a monstrous regex pattern in my code I simply email a confirmation link the user must confirm.
As a tangential anecdote, I always thought it would be interesting to drop a backdoor into some canonical piece of code like this that noobs are bound to copy-paste. It might be the most efficient way to worm your way into the largest number of computers worldwide.
Lookup for an '@' & parse response log from provider to know if addresse works.
Utterly pointless. An email regex tells you that the email address (probably) conforms to a pattern that means it might be a valid email address (for now, until new weird TLDs emerge and the patterns have to change...), but it has no way of telling you whether that address can actually receive mail. `foo@bar` fails these regular expressions and `foo@bar.invalid` passes them, but neither will receive mail. As I have t…
Completely useful, as part of a two step process:1 1. Filter with the regex - what's left has a valid format, making step 2 much saner. 2. Extract and validate the domain name - super simple now, because the domain component is known to be sane. (Optional but good idea 3: Handle exceptions....) Step 1 is almost always the hardest part, now it's mostly done.
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Form...
Note this is super liberal, so user@domainwithnodots (which is RFC valid, but probably also a user error) is still considered valid.