A normal email address exactly has one @ character. There is an infinite number of possible weird things everyone has little though non-zero chance to encounter on every corner of their life.
therefore your implementation should allow this
I wouldn't be sure it should. Implementing support for this has direct and indirect, explicit and implicit costs one will have to consider and decide if that's worth it.
In fact, whatever a human can believe about the world, it won't equal what actually is. So we just take decisions about how precise our models have to be to be practical.
You can never finish a program if you insist it has to be perfect and unbreakable. The only reasonable objective is to make sure it does the job 99.9 % of real-life times.
All that said, there are a number of really good email validators out there in the wild.
One of the oldest can be found at http://isemail.info/about, (along with a test suite to write your own implementation and some sage advice about the basic approaches it's reasonable to take when validating email addresses).
Yes, dependencies aren't completely free conceptually, even when they're distributed free of charge, but why write a crappy validator of your own when there are really good ones available?
Because I really don't want to accept a string with more (or less) than one @ symbol for an e-mail address. Such an address can be valid theoretically but chances are it is incorrect. If somebody submits such a string for their email, 99 in 100 cases it's a typo and the remaining 1 is a person testing you. Not even one real person in a million will use an e-mail address which doesn't have exactly one @ symbol in it.
People can also incorrectly type in their email in a way that looks fine, so I'm skeptical of intentionally not allowing valid email addresses just to cut out a small fraction of those. The isemail.info site recommends a warning if it doesn't look right, but allowing the user to override and use anyway, which seems sensible to me.
(I say this as the proud owner of a lastname.email domain, where the .email TLD was made explicitly for this 8 years, and I still have problems with bad validation.)
You can ask for confirmation if it’s an unusual construction, but denying it outright is user hostile.
Also, how many users are actually manually typing their e-mail address into a form, instead of using autofill?
As the referenced page says, a valid email address is one that can receive email. If you really care about the e-mail address being correct, then you need to validate it by sending a verification e-mail.
Is there a reason to validate an email address? Even if it is valid, you can't use it for anything until you check that the right person owns it and is able to read mail you send there.
I personally accept any string that is between 3 bytes and 1 kilobyte, if they click the link in it then it's good.
As that website I linked says, if the email looks suspicious but is technically valid, ask them "Are you sure you didn't mean this?", but let them choose what they put in.
However, if the address as given is definitely invalid, then you can reject it and explain why. You can offer suggestions here too if any seem reasonable.
A normal email address exactly has one @ character
I've been using <otherperson@email.to@myemaildomain> to respond to people for ages, and this is a completely normal and supported email flow. Who are you to tell other people what is normal? It is not some possible weird thing that other people can use emails that follow the spec and aren't even all that out there.
"The only reasonable objective is to make sure it does the job 99.9 % of real-life times."
If you would be writing software for airplanes, or cars, that would mean lots of crashes per day, with millions x 99.9% being still a lot. If it is financial software, people might loose millions regulary.
But if you make a casual game ... who cares (except the person who lost his highscore achievements).
Comments
A normal email address exactly has one @ character. There is an infinite number of possible weird things everyone has little though non-zero chance to encounter on every corner of their life.
I wouldn't be sure it should. Implementing support for this has direct and indirect, explicit and implicit costs one will have to consider and decide if that's worth it.
In fact, whatever a human can believe about the world, it won't equal what actually is. So we just take decisions about how precise our models have to be to be practical.
You can never finish a program if you insist it has to be perfect and unbreakable. The only reasonable objective is to make sure it does the job 99.9 % of real-life times.
All that said, there are a number of really good email validators out there in the wild.
One of the oldest can be found at http://isemail.info/about, (along with a test suite to write your own implementation and some sage advice about the basic approaches it's reasonable to take when validating email addresses).
Yes, dependencies aren't completely free conceptually, even when they're distributed free of charge, but why write a crappy validator of your own when there are really good ones available?
Because I really don't want to accept a string with more (or less) than one @ symbol for an e-mail address. Such an address can be valid theoretically but chances are it is incorrect. If somebody submits such a string for their email, 99 in 100 cases it's a typo and the remaining 1 is a person testing you. Not even one real person in a million will use an e-mail address which doesn't have exactly one @ symbol in it.
People can also incorrectly type in their email in a way that looks fine, so I'm skeptical of intentionally not allowing valid email addresses just to cut out a small fraction of those. The isemail.info site recommends a warning if it doesn't look right, but allowing the user to override and use anyway, which seems sensible to me.
(I say this as the proud owner of a lastname.email domain, where the .email TLD was made explicitly for this 8 years, and I still have problems with bad validation.)
You can ask for confirmation if it’s an unusual construction, but denying it outright is user hostile.
Also, how many users are actually manually typing their e-mail address into a form, instead of using autofill?
As the referenced page says, a valid email address is one that can receive email. If you really care about the e-mail address being correct, then you need to validate it by sending a verification e-mail.
If somebody wants to register and use an email address with a bang path, that unix beard is out of luck.
Is there a reason to validate an email address? Even if it is valid, you can't use it for anything until you check that the right person owns it and is able to read mail you send there.
I personally accept any string that is between 3 bytes and 1 kilobyte, if they click the link in it then it's good.
Yes - you validate the email address to improve your UX.
It reduces the odds of the user giving you a wrong email address then having to either jump through more hoops to get signed up or give up.
You're absolutely right that the acid test is "can they receive email to it?"
For UX purposes you would use a warning/extra confirmation. If you make the decision to block the user from registering, you are doing something else.
Yeah, precisely.
As that website I linked says, if the email looks suspicious but is technically valid, ask them "Are you sure you didn't mean this?", but let them choose what they put in.
However, if the address as given is definitely invalid, then you can reject it and explain why. You can offer suggestions here too if any seem reasonable.
I've been using <otherperson@email.to@myemaildomain> to respond to people for ages, and this is a completely normal and supported email flow. Who are you to tell other people what is normal? It is not some possible weird thing that other people can use emails that follow the spec and aren't even all that out there.
I have never seen an email address with more than one @.
Can you provide us with an example?
shorel@example.com@otherperson.net
"The only reasonable objective is to make sure it does the job 99.9 % of real-life times."
If you would be writing software for airplanes, or cars, that would mean lots of crashes per day, with millions x 99.9% being still a lot. If it is financial software, people might loose millions regulary.
But if you make a casual game ... who cares (except the person who lost his highscore achievements).
Obviously there are different standards.