4 ms·

I think the best syntax validation technique for email addresses now is found in the HTML spec: https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-a

I think the best syntax validation technique for email addresses now is found in the HTML spec: https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address https://html.spec.whatwg.org/multipage/input.html#valid-e-ma.... As they say, this is a wilful violation of RFC 5322, because that’s simultaneously too strict, too vague and too lax to be useful. They give a grammar, and the following regular expression implementing it: /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/ Remember that the web is a platform that lives and breathes this stuff. A lot of thought went into this grammar for valid email addresses. This is a good way of filtering out obviously bad stuff while allowing all realistic and sane inputs. One part of all this that I’m not aware of the situation around is “8. You can put emojis in the local part.” The HTML spec’s validator is all ASCII. It does remind you to punycode the domain labels, but makes no mention of internationalised local parts, and I’ve never learned about non-ASCII local parts or how well they’re supported. I gather they may require the sender to be capable as well as the receiver, whereas internationalised domain names were made compatible with all systems via punycode.

yjftsjthsd-h 5y ago
> while allowing all realistic and sane inputs. Isn't that a way of saying "while disallowing perfectly valid options"?
- jcranmer 5y ago
  What's disallowed are a) IP literal addresses and b) localparts that require quoting. These email addresses are highly likely to break many processing steps anyways; I've only ever seen category b in sendmail configs (it can be useful for internal email rerouting purposes). There's a distinction to be drawn between the requirements of the actual MTA/MUA/MSA layers and user applications built on top of them. For the latter, considering emails to be invalid if they contain IP literals or quoted localparts is going to be more helpful than harmful (there's less scope for vulnerabilities in doing so). It's just like assuming email addresses are case insensitive: it's inappropriate if you're an MTA, but for everybody else, go ahead and assume they are.
  - Avamander 5y ago
    > What's disallowed are [...] A-ha, but here you're wrong because you've excluded IDNs. This is really why you should not try to be clever.
    - jcranmer 5y ago
      IDN A-labels would still be accepted. Using the U-label is likely to require the same level of support as EAI, because without EAI support, non-ASCII strings are likely to horribly, horribly screw up the lower levels of the stack, and I wouldn't recommend supporting EAI without actually testing to make sure your stack can really handle EAI. (Not to mention EAI localparts being their own can of worms).
      - chrismorgan 5y ago
        And yeah, IDNs are covered by that spec reminding you to punycode domain labels first.
      - Avamander 5y ago
        No normal user will enter their e-mail address in punycode. This is something your own software should be doing.
biztos 5y ago
That regular expression fails to validate a bunch of the examples from the article. And also single-word addresses, which are pretty useful if you want to route email locally. So what makes it the best? [Edit: it also assumes you've already parsed out the "real" address from the rest of the text field, which to me makes it a half-validator at most.]
- crazygringo 5y ago
  Yes, that's the explicit point of it. But it would seem to be the best for general-purpose web use, e.g. signing up for a newsletter with an e-mail address that's pretty much guaranteed not to break anything. Instead of being conservative in output, it's intentionally being conservative in input.
- chrismorgan 5y ago
  Single-word addresses? I presume you main domain names with only one domain label (like “localhost”). Read the grammar again, they’re supported. > it also assumes you've already parsed out the "real" address from the rest of the text field, which to me makes it a half-validator at most I’m confused. The explicit purpose of this stuff is to validate an email address. Not to extract an email address from a freeform text field, which I think is what you’re talking about. Deciding how to do that is a whole ’nother can of worms.
- toomanybeersies 5y ago
  > And also single-word addresses, which are pretty useful if you want to route email locally Unless you're developing an app for an intranet, that's not a concern for most people.
judge2020 5y ago
Hope you're not in PHP, Perl, or Ruby! http://emailregex.com/ http://emailregex.com/
- jcranmer 5y ago
  That's a pretty bad page, given that it gives regexes that match very different things for different languages, without a) explanation what the differences are, and b) any rationale for why you may or may not want to choose between the different versions, let alone c) why different languages "deserve" different versions of the regex. This is already a field where there is a lot of misinformation flying around, and a page that merely regurgitates all of that misinformation without the perspicacity to realize that its purported information is internally incoherent is not helpful.
eli 5y ago
How sure are you that the 61 character limit won’t change in some future DNS improvements? People used to think TLDs would only ever be up to 3 characters long. More importantly, what problem is this even trying to solve? Someone accidentally typing a 300 character domain? If they are intentionally feeding you gibberish they’ll just give you more realistic looking gibberish.
- chrismorgan 5y ago
  You seem unreasonably hostile. I’m absolutely certain that the 63-character limit for domain labels is never going to change, because it’s hardcoded in enormous amounts of software and hardware, and there’s no even vaguely compelling reason to even attempt to change it. But if such a thing did change, then you’d just add this to the extremely long list of things that needed to be updated. People who thought TLDs would only ever be up to three characters long were simply wrong from the very start because they didn’t understand what they were dealing with. (As a simple example, .arpa was there from the start.) Understand that this wasn’t a matter of anything changing, it was that some people misunderstood and thought that a convention they observed was in fact a rule. The problem this sort of validation is solving is weeding out things that are definitely not going to work, as soon as possible, because it’s good to point out problems to users as soon as possible, rather than having something silently fail or only notifying the user about it much later. Syntactic validation isn’t the be-all and end-all of accepting email addresses, but it’s definitely still worthwhile, even though you should generally do other validation based on DNS lookups and/or sending actual emails as well.
crazygringo 5y ago
Huh. Interesting this doesn't support international email [1] addresses, e.g. квіточка@пошта.укр or Dörte@Sörensen.example.com. Seeing as the web has long supported Unicode, where are e-mail addresses currently at in that evolution? Are full Unicode e-mail addresses something that is decently supported today, or still largely theoretical? Is this regex sufficient? What kind of e-mail addresses do people in China most commonly use, for instance? [1] https://en.wikipedia.org/wiki/International_email https://en.wikipedia.org/wiki/International_email
- Avamander 5y ago
  > where are e-mail addresses currently at in that evolution? Baby shoes because of anglosphere programmers that can't fathom people wanting to use their own alphabets and thus forget to support it.
  - xeromal 5y ago
    This is a pretty pessimistic take. The real answer lies somewhere between budget and speed. If someone asked me to support non-latin alphabet, I'd have no idea where to start and the amount of people that would use that feature isn't worth the consideration. It's not that I don't fathom it, it's that I don't have time for that shit.
  - crazygringo 5y ago
    You don't need to be so accusatory or ungenerous about it. Clearly "anglosphere programmers" fathom it every day when they use UTF-8 almost universally in webpages. Also, you know, things like emoji are pretty popular in the "anglosphere" as well. It's obvious that the real reason is an ancient e-mail RFC, and that while upgrading webpages to UTF-8 was relatively easy, in that it only needs 2 parties to support it -- the browser and the server -- upgrading e-mail is almost infinitely more complicated, because you have to wait for virtually all email code in the world to be upgraded, since an e-mail address is pretty useless if it doesn't work everywhere. It other words, it's a coordination problem. Not an ignorance problem. And unfortunately, Punycode [1] doesn't seem to be a particularly viable stepping-stone/compatibility solution here. E.g. if a user tries to use ドメイン名例@example.com and it fails, asking them to instead type in a seemingly-gibberish eckwd4c7cu47r2wf@example.com, where that could also conflict with a real e-mail address of that name. [1] https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode
toomanybeersies 5y ago
I've always just used /^.+@.+\..+$/ That is, "Some characters, an @, some more characters, and a period" I couldn't care less if users want to enter undeliverable email addresses, they won't get emails. All that regex is intended to achieve is ensuring that the user hasn't accidentally filled the wrong field (e.g. tried entering their phone number) or mistyped a punctuation mark (foo#bar.com, foo@bar,com) Strictly speaking, it won't match some valid email addresses, such as IPV6 domains. But if I receive a support ticket complaining that we don't accept email addresses with IPv6 address domain, I'll reply advising that the customer should purchase a domain name or sign up to one of many free email services.

yjftsjthsd-h 5y ago

> while allowing all realistic and sane inputs. Isn't that a way of saying "while disallowing perfectly valid options"?

jcranmer 5y ago
What's disallowed are a) IP literal addresses and b) localparts that require quoting. These email addresses are highly likely to break many processing steps anyways; I've only ever seen category b in sendmail configs (it can be useful for internal email rerouting purposes). There's a distinction to be drawn between the requirements of the actual MTA/MUA/MSA layers and user applications built on top of them. For the latter, considering emails to be invalid if they contain IP literals or quoted localparts is going to be more helpful than harmful (there's less scope for vulnerabilities in doing so). It's just like assuming email addresses are case insensitive: it's inappropriate if you're an MTA, but for everybody else, go ahead and assume they are.
- Avamander 5y ago
  > What's disallowed are [...] A-ha, but here you're wrong because you've excluded IDNs. This is really why you should not try to be clever.
  - jcranmer 5y ago
    IDN A-labels would still be accepted. Using the U-label is likely to require the same level of support as EAI, because without EAI support, non-ASCII strings are likely to horribly, horribly screw up the lower levels of the stack, and I wouldn't recommend supporting EAI without actually testing to make sure your stack can really handle EAI. (Not to mention EAI localparts being their own can of worms).
    - chrismorgan 5y ago
      And yeah, IDNs are covered by that spec reminding you to punycode domain labels first.
    - Avamander 5y ago
      No normal user will enter their e-mail address in punycode. This is something your own software should be doing.

biztos 5y ago

That regular expression fails to validate a bunch of the examples from the article. And also single-word addresses, which are pretty useful if you want to route email locally. So what makes it the best? [Edit: it also assumes you've already parsed out the "real" address from the rest of the text field, which to me makes it a half-validator at most.]

crazygringo 5y ago
Yes, that's the explicit point of it. But it would seem to be the best for general-purpose web use, e.g. signing up for a newsletter with an e-mail address that's pretty much guaranteed not to break anything. Instead of being conservative in output, it's intentionally being conservative in input.
chrismorgan 5y ago
Single-word addresses? I presume you main domain names with only one domain label (like “localhost”). Read the grammar again, they’re supported. > it also assumes you've already parsed out the "real" address from the rest of the text field, which to me makes it a half-validator at most I’m confused. The explicit purpose of this stuff is to validate an email address. Not to extract an email address from a freeform text field, which I think is what you’re talking about. Deciding how to do that is a whole ’nother can of worms.
toomanybeersies 5y ago
> And also single-word addresses, which are pretty useful if you want to route email locally Unless you're developing an app for an intranet, that's not a concern for most people.

judge2020 5y ago

Hope you're not in PHP, Perl, or Ruby! http://emailregex.com/ http://emailregex.com/

jcranmer 5y ago
That's a pretty bad page, given that it gives regexes that match very different things for different languages, without a) explanation what the differences are, and b) any rationale for why you may or may not want to choose between the different versions, let alone c) why different languages "deserve" different versions of the regex. This is already a field where there is a lot of misinformation flying around, and a page that merely regurgitates all of that misinformation without the perspicacity to realize that its purported information is internally incoherent is not helpful.

eli 5y ago

How sure are you that the 61 character limit won’t change in some future DNS improvements? People used to think TLDs would only ever be up to 3 characters long. More importantly, what problem is this even trying to solve? Someone accidentally typing a 300 character domain? If they are intentionally feeding you gibberish they’ll just give you more realistic looking gibberish.

chrismorgan 5y ago
You seem unreasonably hostile. I’m absolutely certain that the 63-character limit for domain labels is never going to change, because it’s hardcoded in enormous amounts of software and hardware, and there’s no even vaguely compelling reason to even attempt to change it. But if such a thing did change, then you’d just add this to the extremely long list of things that needed to be updated. People who thought TLDs would only ever be up to three characters long were simply wrong from the very start because they didn’t understand what they were dealing with. (As a simple example, .arpa was there from the start.) Understand that this wasn’t a matter of anything changing, it was that some people misunderstood and thought that a convention they observed was in fact a rule. The problem this sort of validation is solving is weeding out things that are definitely not going to work, as soon as possible, because it’s good to point out problems to users as soon as possible, rather than having something silently fail or only notifying the user about it much later. Syntactic validation isn’t the be-all and end-all of accepting email addresses, but it’s definitely still worthwhile, even though you should generally do other validation based on DNS lookups and/or sending actual emails as well.

crazygringo 5y ago

Huh. Interesting this doesn't support international email [1] addresses, e.g. квіточка@пошта.укр or Dörte@Sörensen.example.com. Seeing as the web has long supported Unicode, where are e-mail addresses currently at in that evolution? Are full Unicode e-mail addresses something that is decently supported today, or still largely theoretical? Is this regex sufficient? What kind of e-mail addresses do people in China most commonly use, for instance? [1] https://en.wikipedia.org/wiki/International_email https://en.wikipedia.org/wiki/International_email

Avamander 5y ago
> where are e-mail addresses currently at in that evolution? Baby shoes because of anglosphere programmers that can't fathom people wanting to use their own alphabets and thus forget to support it.
- xeromal 5y ago
  This is a pretty pessimistic take. The real answer lies somewhere between budget and speed. If someone asked me to support non-latin alphabet, I'd have no idea where to start and the amount of people that would use that feature isn't worth the consideration. It's not that I don't fathom it, it's that I don't have time for that shit.
- crazygringo 5y ago
  You don't need to be so accusatory or ungenerous about it. Clearly "anglosphere programmers" fathom it every day when they use UTF-8 almost universally in webpages. Also, you know, things like emoji are pretty popular in the "anglosphere" as well. It's obvious that the real reason is an ancient e-mail RFC, and that while upgrading webpages to UTF-8 was relatively easy, in that it only needs 2 parties to support it -- the browser and the server -- upgrading e-mail is almost infinitely more complicated, because you have to wait for virtually all email code in the world to be upgraded, since an e-mail address is pretty useless if it doesn't work everywhere. It other words, it's a coordination problem. Not an ignorance problem. And unfortunately, Punycode [1] doesn't seem to be a particularly viable stepping-stone/compatibility solution here. E.g. if a user tries to use ドメイン名例@example.com and it fails, asking them to instead type in a seemingly-gibberish eckwd4c7cu47r2wf@example.com, where that could also conflict with a real e-mail address of that name. [1] https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode

toomanybeersies 5y ago

I've always just used /^.+@.+\..+$/ That is, "Some characters, an @, some more characters, and a period" I couldn't care less if users want to enter undeliverable email addresses, they won't get emails. All that regex is intended to achieve is ensuring that the user hasn't accidentally filled the wrong field (e.g. tried entering their phone number) or mistyped a punctuation mark (foo#bar.com, foo@bar,com) Strictly speaking, it won't match some valid email addresses, such as IPV6 domains. But if I receive a support ticket complaining that we don't accept email addresses with IPv6 address domain, I'll reply advising that the customer should purchase a domain name or sign up to one of many free email services.