4 ms·

This is neat. A couple of points: 1- Client side validation is easy to circumvent. If you use this you have to make sure it is for UI only and that the real v

This is neat. A couple of points: 1- Client side validation is easy to circumvent. If you use this you have to make sure it is for UI only and that the real validation happens server side. 2- Using regex for email validation is fraught with issues. Probably the most salient one is that there are a million expressions out there. People run a quick google search, grab one and move on without knowing what they just plugged into their code. This particular tool will, for example, pass "m@apple.comm" as valid. Other than that, I am sure this is a great time saver.

dinkumthinkum 14y ago
1. I agree, of course. Surely, everyone knows this right? 2. True, but you have to do something. :) What exactly is wrong with m@apple.comm? That could be valid domain at some point, right? You could filter those out but it's almost a preference sort of question. Does anyone think it would make sense to have "warning" level of validation for email addresses and let the user decide on these sort of examples? Just throwing it out there.
- jiggy2011 14y ago
  To fix that, you can do a DNS lookup and check the domain has a valid MX record.
  - robomartin 14y ago
    Just be careful when you do this. If you don't use an absolute FQDN you can trigger severe delay in getting a response from the resolver. It can take twenty or thirty seconds (or more) to get a response.
  - guillaumepotier 14y ago
    At some point if you want to be absolutely sure, you'll have to send a validation link / email and not doing it frontend in JavaScript ;)
  - iambibhas 14y ago
    HTTP calls for client side validation? That's a great idea!
    - optymizer 14y ago
      "This username has already been taken."
SpoonMeiser 14y ago
re point 2. I don't see a problem with using a regex to validate email, unless you get false negatives. Rejecting anything that could be a valid e-mail address is bad and will cause frustration for someone at some point. I don't think allowing validly formed e-mail addresses that don't have corresponding accounts (or even domains - consider a web app working in offline mode) is a bad thing, especially when taken with point 1, as surely the point of client side validation is a heads up to the user that the data is wrong, rather than actual validation?
- robomartin 14y ago
  It's highly application dependent, right? Say it's a signup form. Your validator lets a bad email through. The potential client/customer left. You can't email them to ask for correct email. They are gone. They may never come back (depends of what they were there for, right?). In that case I would want to do as much as might be reasonable in order to ensure that I capture someone who might eventually translate into revenue. In other cases it might be just fine to store absolute gibberish and deal with it later. That said, if you have an incredibly popular site and are receiving thousands upon thousands of sign-ups per day, do you really want to store junk? Someone is going to have to go clean it up before it is of any use. Anyhow, my main point, perhaps, is that one should understand what these magic regex email validators are and are not. That's all. The reason I bring this up whenever relevant is because I have been bitten by this problem in the past. I only understood the problem when an existing customer informed me that they could not sign-up to receive info on a new product because my email validator was kicking them out. He just picked-up the phone and called me. I never did learn how many people I lost because of that damn regex I grabbed from an authoritative source on the 'net.
  - thefreeman 14y ago
    Nobody thinks a regular expression will prevent someone from signing up with an email that doesn't exist. If you absolutely must have valid email addresses the only sure way is to make them confirm it with information from an email sent to the address.
jdietrich 14y ago
Virtually every attempt at email address validation is overly strict, because the relevant RFC standards are vastly more liberal than people realise. Non-ascii characters above U+007F are valid since RFC 6530. An IP address in the domain part is valid. An @ in the name part is valid if it's escaped. "異常.(),:;<>[]\".ຜິດປົກກະຕິ.\"அசாதரண@\\ \"অস্বাভাবিক\".არაჩ"@[IPv6:3ffe:1900:4545:3:200:f8ff:fe21:67cf] is a perfectly valid email address.

dinkumthinkum 14y ago

1. I agree, of course. Surely, everyone knows this right? 2. True, but you have to do something. :) What exactly is wrong with m@apple.comm? That could be valid domain at some point, right? You could filter those out but it's almost a preference sort of question. Does anyone think it would make sense to have "warning" level of validation for email addresses and let the user decide on these sort of examples? Just throwing it out there.

jiggy2011 14y ago
To fix that, you can do a DNS lookup and check the domain has a valid MX record.
- robomartin 14y ago
  Just be careful when you do this. If you don't use an absolute FQDN you can trigger severe delay in getting a response from the resolver. It can take twenty or thirty seconds (or more) to get a response.
- guillaumepotier 14y ago
  At some point if you want to be absolutely sure, you'll have to send a validation link / email and not doing it frontend in JavaScript ;)
- iambibhas 14y ago
  HTTP calls for client side validation? That's a great idea!
  - optymizer 14y ago
    "This username has already been taken."

SpoonMeiser 14y ago

re point 2. I don't see a problem with using a regex to validate email, unless you get false negatives. Rejecting anything that could be a valid e-mail address is bad and will cause frustration for someone at some point. I don't think allowing validly formed e-mail addresses that don't have corresponding accounts (or even domains - consider a web app working in offline mode) is a bad thing, especially when taken with point 1, as surely the point of client side validation is a heads up to the user that the data is wrong, rather than actual validation?

robomartin 14y ago
It's highly application dependent, right? Say it's a signup form. Your validator lets a bad email through. The potential client/customer left. You can't email them to ask for correct email. They are gone. They may never come back (depends of what they were there for, right?). In that case I would want to do as much as might be reasonable in order to ensure that I capture someone who might eventually translate into revenue. In other cases it might be just fine to store absolute gibberish and deal with it later. That said, if you have an incredibly popular site and are receiving thousands upon thousands of sign-ups per day, do you really want to store junk? Someone is going to have to go clean it up before it is of any use. Anyhow, my main point, perhaps, is that one should understand what these magic regex email validators are and are not. That's all. The reason I bring this up whenever relevant is because I have been bitten by this problem in the past. I only understood the problem when an existing customer informed me that they could not sign-up to receive info on a new product because my email validator was kicking them out. He just picked-up the phone and called me. I never did learn how many people I lost because of that damn regex I grabbed from an authoritative source on the 'net.
- thefreeman 14y ago
  Nobody thinks a regular expression will prevent someone from signing up with an email that doesn't exist. If you absolutely must have valid email addresses the only sure way is to make them confirm it with information from an email sent to the address.

jdietrich 14y ago

Virtually every attempt at email address validation is overly strict, because the relevant RFC standards are vastly more liberal than people realise. Non-ascii characters above U+007F are valid since RFC 6530. An IP address in the domain part is valid. An @ in the name part is valid if it's escaped. "異常.(),:;<>[]\".ຜິດປົກກະຕິ.\"அசாதரண@\\ \"অস্বাভাবিক\".არაჩ"@[IPv6:3ffe:1900:4545:3:200:f8ff:fe21:67cf] is a perfectly valid email address.