5 ms·

I was thinking of using this as the basis for some email validation as I got a lot of incorrect email addresses in form posts.

by dan1234 10y ago

Freak_NL 10y ago
Please don't. A lot has been written about email address validation (search HN for a few good discussions); it is horrendously complex to get right. Any mistake or oversight means perfectly valid email addresses won't work, and maintaining your home-grown solution means keeping tabs on any updates to this domain suffix list and other relevant standards. The most sensible approach (in my opinion) is to validate with this minimal regex: /.+@.+/ Essentially just requiring an at-mark between two other bits of text. After that send a confirmation email to see if it works. That is pretty much fool-proof and low maintenance. If you absolutely must help the user in preventing any common mistakes, use a library that provides hints in the UI for those presumed errors without actually invalidating the input. There are JavaScript libraries that do this fairly well.
- brb3 10y ago
  > Essentially just requiring an at-mark between two other bits of text. I've been using this regex to make sure there actually is text before and after the @ /.+@.+/
  - Freak_NL 10y ago
    You are right of course. A typo on my end (fixed).
  - infogulch 10y ago
    Can there be more than one @ or whitespace? If not you could use: /^[^@\s]+@[^@\s]+$/ Filtering out emails with multiple @'s and whitespace seems like an obvious win to help prevent typos and copy-paste errors.
    - jwilk 10y ago
      Yes, the are valid e-mail addresses that contain whitespace or multiple @s. Wikipedia <https://en.wikipedia.org/wiki/Email_address#Valid_email_addresses https://en.wikipedia.org/wiki/Email_address#Valid_email_addr... > gives the following example: "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com
      - infogulch 10y ago
        Oh my. Nevermind. `/.+@.+/` it is.
      - Freak_NL 10y ago
        Exactly. It is very much our nature as programmers to attempt to capture this seemingly trivial bit of structured text into seemingly innocuous programming rules, but the rewards of the added complexity are just too meager. Even if an email address validates, it still doesn't mean that you have a working email address. Sending an email is the only way to be sure, and if you are already doing that, then why risk excluding valid email addresses with a decidedly non-trivial regex? There are regexes out there that capture all the complexity of valid email addresses today (but who knows if they'll work with, say, next year's additions to the top-level domains?), and you can copy them from StackOverflow if you really want them; but why bother?
      - jcranmer 10y ago
        It is safe in almost all applications to assume that quoted-string local-parts do not constitute a valid email address (ditto for domain literals).
    - wongarsu 10y ago
      Whitespace in front of the @ is only allowed within quotes, and any quoted part must be seperated by dots from unqoted parts. "my address"@example.com is allowed, as is my." ".address@example.com, but not my"address"@example.com. Once you get that into a regex format, remember that a quoted dot is different from an unqoted dot, and don't forget that you handle comments within email addesses correctly. There are plenty of reasons why people say not to use regex to validate email addresses.
throwanem 10y ago
Freak_NL says: > Please don't. He is correct. Seriously. Don't. The right way to validate an email address, if that's something you need to do, is by sending it a message with a link and a response code, and seeing whether the user clicks the link or enters the code. This is the only right way. There are many wrong ways. They make people unhappy. They will make you unhappy. Do not use them. You cannot validate email addresses for shape and form. The sole invariant is that there be at least three characters one of which is @. Everything beyond that is in the hands of the DNS and the domain's MTA. You cannot predict every fashion in which they will behave. You should not try to. Have you seen the regex that correctly matches every variant of email address form described in RFC 822? It is five kilobytes long. "Ah," you may now think, "I can use that!" You should not. There are new standards with new variations. The regex is incomplete. It will be incomplete forever. It is a five-kilobyte Perl regex. No one will ever understand it well enough to extend it. Just send a link and a code. Ask the user to click on the link or give you the code. When you have received the click or the code, you know the email is valid. When you have not, assume it is not. This is the method that works. It is the only method that works. Use this method and be happy. Use any other and be sad. Which you prefer is up to you.
- snowwolf 10y ago
  I prefer to do email suggestion rather than validation - The only validation I have is that it should contain an @. And then use something like http://getmailcheck.org/ http://getmailcheck.org/ to suggest spelling corrections for common domains. We saw a massive reduction in bad emails just by implementing this without having to annoy users with incorrectly implemented validation rules.
- geofft 10y ago
  > You cannot validate email addresses for shape and form. The sole invariant is that there be at least three characters one of which is @. Everything beyond that is in the hands of the DNS and the domain's MTA. You cannot predict every fashion in which they will behave. You should not try to. I used to agree with this viewpoint, but now I'm having some doubts. Suppose I enter the email address "geofft@example.net@example.com". It validates according to your rule. Where does it go? Suppose, furthermore, that I upgrade my servers and they start parsing it differently. They're allowed to do that, right? Maybe my old MTA sent a confirmation email to example.net, and the new one is now sending emails to a user named "geofft@example.net" at example.com. Haven't I just done something very wrong by allowing a user to trick me into sending emails to an unvalidated address? Isn't this both a violation of the Postel principle ("conservative in what you send to others") and a security hole? It seems like it would be better for my application to parse the email address and validate what it's doing, and store only unambiguously-parseable addresses. Or maybe they're not allowed to parse it differently. Maybe there's a single consistent way to parse geofft@example.net@example.com, and every single email application I might use will get it right. What is this esoteric lore that email applications know that my application cannot? If they can parse it, can't I?
spc476 10y ago
If you feel you really have to validate an email address without sending an email to said address, don't use a regex. Use something that's meant for parsing, like LPeg (for example: https://github.com/spc476/LPeg-Parsers/blob/ee63df57826fd5ef62eac5669b444e5d7c9da6ff/email.lua#L504 https://github.com/spc476/LPeg-Parsers/blob/ee63df57826fd5ef... which handles the RFC grammar, including comments) or lex/yacc or something other than a regex.

I was thinking of using this as the basis for some email validation as I got a lot of incorrect email addresses in form posts.

by dan1234 10y ago

I was thinking of using this as the basis for some email validation as I got a lot of incorrect email addresses in form posts.

Freak_NL 10y ago

Please don't. A lot has been written about email address validation (search HN for a few good discussions); it is horrendously complex to get right. Any mistake or oversight means perfectly valid email addresses won't work, and maintaining your home-grown solution means keeping tabs on any updates to this domain suffix list and other relevant standards. The most sensible approach (in my opinion) is to validate with this minimal regex: /.+@.+/ Essentially just requiring an at-mark between two other bits of text. After that send a confirmation email to see if it works. That is pretty much fool-proof and low maintenance. If you absolutely must help the user in preventing any common mistakes, use a library that provides hints in the UI for those presumed errors without actually invalidating the input. There are JavaScript libraries that do this fairly well.

brb3 10y ago
> Essentially just requiring an at-mark between two other bits of text. I've been using this regex to make sure there actually is text before and after the @ /.+@.+/
- Freak_NL 10y ago
  You are right of course. A typo on my end (fixed).
- infogulch 10y ago
  Can there be more than one @ or whitespace? If not you could use: /^[^@\s]+@[^@\s]+$/ Filtering out emails with multiple @'s and whitespace seems like an obvious win to help prevent typos and copy-paste errors.
  - jwilk 10y ago
    Yes, the are valid e-mail addresses that contain whitespace or multiple @s. Wikipedia <https://en.wikipedia.org/wiki/Email_address#Valid_email_addresses https://en.wikipedia.org/wiki/Email_address#Valid_email_addr... > gives the following example: "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com
    - infogulch 10y ago
      Oh my. Nevermind. `/.+@.+/` it is.
    - Freak_NL 10y ago
      Exactly. It is very much our nature as programmers to attempt to capture this seemingly trivial bit of structured text into seemingly innocuous programming rules, but the rewards of the added complexity are just too meager. Even if an email address validates, it still doesn't mean that you have a working email address. Sending an email is the only way to be sure, and if you are already doing that, then why risk excluding valid email addresses with a decidedly non-trivial regex? There are regexes out there that capture all the complexity of valid email addresses today (but who knows if they'll work with, say, next year's additions to the top-level domains?), and you can copy them from StackOverflow if you really want them; but why bother?
    - jcranmer 10y ago
      It is safe in almost all applications to assume that quoted-string local-parts do not constitute a valid email address (ditto for domain literals).
  - wongarsu 10y ago
    Whitespace in front of the @ is only allowed within quotes, and any quoted part must be seperated by dots from unqoted parts. "my address"@example.com is allowed, as is my." ".address@example.com, but not my"address"@example.com. Once you get that into a regex format, remember that a quoted dot is different from an unqoted dot, and don't forget that you handle comments within email addesses correctly. There are plenty of reasons why people say not to use regex to validate email addresses.

throwanem 10y ago

Freak_NL says: > Please don't. He is correct. Seriously. Don't. The right way to validate an email address, if that's something you need to do, is by sending it a message with a link and a response code, and seeing whether the user clicks the link or enters the code. This is the only right way. There are many wrong ways. They make people unhappy. They will make you unhappy. Do not use them. You cannot validate email addresses for shape and form. The sole invariant is that there be at least three characters one of which is @. Everything beyond that is in the hands of the DNS and the domain's MTA. You cannot predict every fashion in which they will behave. You should not try to. Have you seen the regex that correctly matches every variant of email address form described in RFC 822? It is five kilobytes long. "Ah," you may now think, "I can use that!" You should not. There are new standards with new variations. The regex is incomplete. It will be incomplete forever. It is a five-kilobyte Perl regex. No one will ever understand it well enough to extend it. Just send a link and a code. Ask the user to click on the link or give you the code. When you have received the click or the code, you know the email is valid. When you have not, assume it is not. This is the method that works. It is the only method that works. Use this method and be happy. Use any other and be sad. Which you prefer is up to you.

snowwolf 10y ago
I prefer to do email suggestion rather than validation - The only validation I have is that it should contain an @. And then use something like http://getmailcheck.org/ http://getmailcheck.org/ to suggest spelling corrections for common domains. We saw a massive reduction in bad emails just by implementing this without having to annoy users with incorrectly implemented validation rules.
geofft 10y ago
> You cannot validate email addresses for shape and form. The sole invariant is that there be at least three characters one of which is @. Everything beyond that is in the hands of the DNS and the domain's MTA. You cannot predict every fashion in which they will behave. You should not try to. I used to agree with this viewpoint, but now I'm having some doubts. Suppose I enter the email address "geofft@example.net@example.com". It validates according to your rule. Where does it go? Suppose, furthermore, that I upgrade my servers and they start parsing it differently. They're allowed to do that, right? Maybe my old MTA sent a confirmation email to example.net, and the new one is now sending emails to a user named "geofft@example.net" at example.com. Haven't I just done something very wrong by allowing a user to trick me into sending emails to an unvalidated address? Isn't this both a violation of the Postel principle ("conservative in what you send to others") and a security hole? It seems like it would be better for my application to parse the email address and validate what it's doing, and store only unambiguously-parseable addresses. Or maybe they're not allowed to parse it differently. Maybe there's a single consistent way to parse geofft@example.net@example.com, and every single email application I might use will get it right. What is this esoteric lore that email applications know that my application cannot? If they can parse it, can't I?

spc476 10y ago

If you feel you really have to validate an email address without sending an email to said address, don't use a regex. Use something that's meant for parsing, like LPeg (for example: https://github.com/spc476/LPeg-Parsers/blob/ee63df57826fd5ef62eac5669b444e5d7c9da6ff/email.lua#L504 https://github.com/spc476/LPeg-Parsers/blob/ee63df57826fd5ef... which handles the RFC grammar, including comments) or lex/yacc or something other than a regex.