From the perspective of a user typing their own email address correctly, I use text substitution on OS X and iOS to never type my full email address. ex fg --> foo@gmail.com
fg
The Correct Way to Validate Email Addresses
11–20 of 405 posts
Re: The Correct Way to Validate Email Addresses
#12This is the best comprehensive way that I've found:
https://github.com/kdisneur/email_checker
It breaks down into 3 parts that can be used either independently or as a whole: format, MX and SMTP.
Re: The Correct Way to Validate Email Addresses
#13I always assumed it was more a sanitization issue for security's sake. By allowing only a simple subset ("common") email address type, you can be ambivalent about what email server is running and how it reacts to the wide variety of specially crafted email addresses.
With no validation other than sending the email, you have to know, for example, what the server would do with an email address that claims to be @localhost. Now it becomes a problem- or at least a question and concern- for the backend system. Whether the backend interprets root@localhost as valid and does exactly what it's told or rejects it due to some configuration- it has become a backend complication and a DOS attack vector.
A simple policy of only handling a subset- the common class of email addresses- is one of the things that allows us to have a simple mental model of what the MTA is supposed to do. The fact that it sometimes caught a type-o, or not, is incidental. "Invalid email" wasn't meant to imply the email address doesn't fit the spec- it was meant to imply that a particular site or service has chosen not to accept email addresses like that.
Or at least that's what I assumed :-)
Re: The Correct Way to Validate Email Addresses
#14Earlier quoted context omitted.
Also relevant was, "If you have a well laid-out form with a label that says “email”, and the user enters an ‘@’ symbol somewhere, then it’s safe to say they understood that they were supposed to be entering an email address." In other words, it does make sense to check that they entered an '@' symbol somewhere, since it shows that they understood it was an email field. Any 'validation' beyond that is useless.
How about more than one @ sign? Does the email address spec exclude the possibility of more than one @ symbols?
Nope, that's valid if one of them is quoted: "very.unusual.@.unusual.com"@example.com
Re: The Correct Way to Validate Email Addresses
#15Earlier quoted context omitted.
Also relevant was, "If you have a well laid-out form with a label that says “email”, and the user enters an ‘@’ symbol somewhere, then it’s safe to say they understood that they were supposed to be entering an email address." In other words, it does make sense to check that they entered an '@' symbol somewhere, since it shows that they understood it was an email field. Any 'validation' beyond that is useless.
How about more than one @ sign? Does the email address spec exclude the possibility of more than one @ symbols?
[deleted]
Re: The Correct Way to Validate Email Addresses
#16Yes, please do send activation emails (or perhaps a personal confirmation email if you are establishing contact with someone that wrote down an address for you).
Those of us with firstnamelastname@commonhost will appreciate not getting bills and job offers and such.
Re: The Correct Way to Validate Email Addresses
#17Earlier quoted context omitted.
Also relevant was, "If you have a well laid-out form with a label that says “email”, and the user enters an ‘@’ symbol somewhere, then it’s safe to say they understood that they were supposed to be entering an email address." In other words, it does make sense to check that they entered an '@' symbol somewhere, since it shows that they understood it was an email field. Any 'validation' beyond that is useless.
How about more than one @ sign? Does the email address spec exclude the possibility of more than one @ symbols?
It doesn't matter. If they have typed an @, they probably understand that it's an email field. Trying to validate to the spec beyond that is pointless, for reasons thoroughly covered in the article.
Re: The Correct Way to Validate Email Addresses
#18In Dada Mail [0], there's quite a few steps to figuring out if the email address submitted for a mailing list subscription is valid, but most of it can really be organized under sanitizing the data you receive, which you should be doing anyways. Yes, we do validation for form of an address client side (which helps with hitting the server side so much), but we'll do it again server side. We also look at stats on how many times an address was submitted before, as well as per ip address over time across all fuctions of the app (as well as specifically for subscribing). Oh, and even if it's valid, and "real", sometimes we don't want to work with it either, ie: it shows up on something like StopFormSpam. It's actually a ton of work and much to orchestrate.
Re: The Correct Way to Validate Email Addresses
#19I do a lot of optin email. Here are some examples of bounced emails that people use to sign up:
* somename@gmail.co
* anothername@yhoo.com
* myemail@hotmial.com
These are very common errors that occur nearly every day. A regex isn't going to help here. What does help, is a notification that asks people to verify what they typed –– if the email contains an obvious, common error, such as one listed above.
Re: The Correct Way to Validate Email Addresses
#20Hmm, sorry but I don't buy that the "correct way to validate" is not to validate the input.
Email addresses aren't a special enough case to be handled differently than any other user input, which we always validate to both sanitize and show client-side errors, if nothing else.
Sure, the complete regex is complex, but it is defined and is hardly unconquerable. Look at Django's `EmailValidator` implementation for example [0] that is mature and well tested [1].
The author has not convinced me that ignoring validation is the right choice when options with a scope so thorough exist.
[0]: https://github.com/django/django/blob/master/django/core/val...
[1]: https://github.com/django/django/blob/a9215b7c36bff232bcc941...