3 ms·

Our strategy, ensure there is a "@" and some text before and after the "@". We require email validation (click a link in an email) so if they enter in a bad em

Our strategy, ensure there is a "@" and some text before and after the "@". We require email validation (click a link in an email) so if they enter in a bad email we catch it on the validation part anyhow.

realusername 9y ago
I do generally the same, it probably validates some invalid addresses but at least it's the most realistic filter.
kikoreis 9y ago
What do you consider "some text"?
- thecatspaw 9y ago
  Im assuming .+
nabeards 9y ago
Yep, I do exactly the same. Let the mail servers validate the address.
onion2k 9y ago
I think this demonstrates why we validate things. There are two reasons - to ensure the data is correct, and to catch errors that the user has made. On the face of it they sound the same but they're not. As far as your service is concerned a 'correct' email address is anything that looks a bit like an email address. As far as the user is concerned a correct email address is specifically their email address. Your pattern works well enough for the first part but not the second. Any validation pattern that caters for the user should be trying to catch instances where the user has entered their address incorrectly. That means validating things like the general pattern ('does it have a @'), checking the TLD ('is the TLD part of the domain in this huge array'), and catching weird characters ('did the user really mean to use a ®'). Even if the validation fails the user should be able to submit their address (this is client side after all; the user can just disable it), but they should be informed that it appears there could be a reason to double check it first.
- RandallBrown 9y ago
  It's nearly impossible to validate against TLD since there are arbitrary TLDs now. I've always checked for something@something.something then you rely on a verification email. If you want to make sure they typed in their email correctly, then make them type it in twice.
  - onion2k 9y ago
    Your client side validation should be looking for warning signs rather than blocking the user though. You can use a distance algorithm (eg soundex) to check against a list of known TLDs and warn the user to check their address if it's close to a known TLD but not an exact match. Anything that's not close to a known value should result in a different warning. Nothing should stop the user from submitting their value, but the form should try to help them get the right value the first time around. That's what client side validation is for. It is not for blocking incorrect values (because it's trivial to get around it).
toomanybeersies 9y ago
The one time I had to validate email addresses without using another library, I settled on /.+@.+\..+/ Basically the same as yours, but validate that a TLD exists. Technically, this would fail on a few valid email addresses: foo@localhost, foo@.co, or foo@2001:0db8:85a3:0000:0000:8a2e:0370:7334 All those are valid, but we decided that none of those would apply to any of our customers.

realusername 9y ago

I do generally the same, it probably validates some invalid addresses but at least it's the most realistic filter.

kikoreis 9y ago

What do you consider "some text"?

thecatspaw 9y ago
Im assuming .+

nabeards 9y ago

Yep, I do exactly the same. Let the mail servers validate the address.

onion2k 9y ago

I think this demonstrates why we validate things. There are two reasons - to ensure the data is correct, and to catch errors that the user has made. On the face of it they sound the same but they're not. As far as your service is concerned a 'correct' email address is anything that looks a bit like an email address. As far as the user is concerned a correct email address is specifically their email address. Your pattern works well enough for the first part but not the second. Any validation pattern that caters for the user should be trying to catch instances where the user has entered their address incorrectly. That means validating things like the general pattern ('does it have a @'), checking the TLD ('is the TLD part of the domain in this huge array'), and catching weird characters ('did the user really mean to use a ®'). Even if the validation fails the user should be able to submit their address (this is client side after all; the user can just disable it), but they should be informed that it appears there could be a reason to double check it first.

RandallBrown 9y ago
It's nearly impossible to validate against TLD since there are arbitrary TLDs now. I've always checked for something@something.something then you rely on a verification email. If you want to make sure they typed in their email correctly, then make them type it in twice.
- onion2k 9y ago
  Your client side validation should be looking for warning signs rather than blocking the user though. You can use a distance algorithm (eg soundex) to check against a list of known TLDs and warn the user to check their address if it's close to a known TLD but not an exact match. Anything that's not close to a known value should result in a different warning. Nothing should stop the user from submitting their value, but the form should try to help them get the right value the first time around. That's what client side validation is for. It is not for blocking incorrect values (because it's trivial to get around it).

toomanybeersies 9y ago

The one time I had to validate email addresses without using another library, I settled on /.+@.+\..+/ Basically the same as yours, but validate that a TLD exists. Technically, this would fail on a few valid email addresses: foo@localhost, foo@.co, or foo@2001:0db8:85a3:0000:0000:8a2e:0370:7334 All those are valid, but we decided that none of those would apply to any of our customers.