5 ms·

I tried using that expression for a while, but then a user with a valid email address containing upper unicode characters showed up. I switched to a simpler exp

I tried using that expression for a while, but then a user with a valid email address containing upper unicode characters showed up. I switched to a simpler expression: ^[^@\s\x00-\x1f]+@[^@\s\x00-\x1f.]+(:?\.[^@\s\x00-\x1f.]+)*$ It requires exactly one "@", disallows whitespace and control characters, prevents repeated dots in the domain name, and ensures the domain doesn't end with a dot. It catches a few typos and I think it allows every real email address I've heard of.

easrng 5y ago
Domains ending with a dot are valid though, and it's needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)
- hathawsh 5y ago
  Good to know. I guess I'll simplify again. Besides, I wonder whether the expression is vulnerable to catastrophic backtracking.
- Beltalowda 5y ago
  > it's needed sometimes When is this needed in the context of a Rails app? You never want to send emails to local hosts, and emails directly on the TLD is possible, but very little will work with them in practice.
  - turminal 5y ago
    > You never want to send emails to local hosts That's not entirely true, it depends on how your mailing infrastructure is set up.
    - Beltalowda 5y ago
      But in the context of a web app though? That's the key part: you're taking in email addresses from myapp.example.com. For other cases: sure, local email addresses can be useful (not often these days, but sometimes still are). But in this context I'm not really seeing any use case.
      - bbatha 5y ago
        At previous $work, I wrote a rails app that managed releases. On the app you could sign up for email notifications when your change was released. These went through the unix local email system. So yes there is very much a use case
        lolinder 5y ago
        It's still a bit silly to tell every SaaS developer that they shouldn't validate that they have a normal-looking domain because some people's use cases call for sending emails to local addresses or to TLDs directly. If a developer needs to handle those cases, they know already, and they're in a vanishingly small minority.
- Biganon 5y ago
  I'm pretty sure the one guy behind ai. doesn't justify that you change your regex for him. Let's not be overly pedantic.
- campital 5y ago
  https://en.wikipedia.org/wiki/Top-level_domain#Dotless_domains https://en.wikipedia.org/wiki/Top-level_domain#Dotless_domai...
- Supermancho 5y ago
  > Domains ending with a dot are valid though, That doesn't mean you have to support their use. I have never seen a company support an email ending in a period and the world seems to continue along.
daurnimator 5y ago
I invite you to try my test suite at https://github.com/daurnimator/lpeg_patterns/blob/master/spec/email_spec.lua https://github.com/daurnimator/lpeg_patterns/blob/master/spe...
qwerty456127 5y ago
> containing upper unicode characters Are e-mail addresses case-sensitive? I would always lowercase&trim a string meant to represent an e-mail address (or a domain name) before doing anything else with it.
- electroly 5y ago
  The local-part before the @ can be case-sensitive, yes. I've never heard of a mail server that treats it as such, but the RFC says it's case sensitive.
  - deleted 5y ago
    [deleted]
- jeroenhd 5y ago
  Not all uppercase characters have just one lowercase representation, and not all lowercase characters have an uppercase character. If you try to make the addresses case insensitive, you're bound to run into unnecessary complexities at some point. Email addresses aren't case insensitive in nature, but many commercial mail services (and misguided developers) assume they are.
- hathawsh 5y ago
  To be clear, by "upper" unicode characters I mean non-ASCII international characters, not uppercase characters. For example, 我買@屋企.香港 is now a valid email address. [1] 1. https://en.wikipedia.org/wiki/Email_address#Internationalization_examples https://en.wikipedia.org/wiki/Email_address#Internationaliza...
bobbylarrybobby 5y ago
I'm pretty sure email addresses are allowed to have multiple @'s. I believe everything after the first is (supposed to be) considered part of the domain.
- chrismorgan 5y ago
  Domain labels cannot contain @. If you support comments or quoted strings (e.g. (@)."@"@example) then you can get multiple at signs in an address, but in practice their only use these days is attacks where you confuse a badly-written server, which is part of why the web actively decided to disallow them.
  - eadmund 5y ago
    > in practice their only use these days is attacks where you confuse a badly-written server Or, you know, if you actually want to use an at sign in the manner allowed by the RFCs. That's the point of standards: if something is allowed, then … it is allowed. Refusing to accept behaviour permitted by the standard is just broken.
    - chrismorgan 5y ago
      Usage is what matters. Standards documents only have value as long as people follow them; once enough people deviate, they cease to have meaning. This is thoroughly the case with a lot of stuff pertaining to email: if you want to parse arbitrary emails, for example, the relevant MIME RFCs are altogether insufficient, because too many people have done it incorrectly de jure, often to the point where it’s no longer incorrect de facto because everyone supports the deviation. (This is a deviation from spec in the direction of permission.) By hearsay alone, I say: comments and quoted strings in email addresses are, de facto, more or less dead. Comments especially, which were intended just as a compatibility measure for stuff from over forty years ago (when this was being developed organically, before there was any real spec). Most software whose direct business is email (that is, MUAs and MTAs) will more or less support them for historical reasons, but newer MUAs are likely not to support them in full (again especially comments), and I suspect the considerable majority of other software that deals in email addresses won’t support one or both of them. (This is a deviation from spec in the direction of restriction.)

easrng 5y ago

Domains ending with a dot are valid though, and it's needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)

hathawsh 5y ago
Good to know. I guess I'll simplify again. Besides, I wonder whether the expression is vulnerable to catastrophic backtracking.
Beltalowda 5y ago
> it's needed sometimes When is this needed in the context of a Rails app? You never want to send emails to local hosts, and emails directly on the TLD is possible, but very little will work with them in practice.
- turminal 5y ago
  > You never want to send emails to local hosts That's not entirely true, it depends on how your mailing infrastructure is set up.
  - Beltalowda 5y ago
    But in the context of a web app though? That's the key part: you're taking in email addresses from myapp.example.com. For other cases: sure, local email addresses can be useful (not often these days, but sometimes still are). But in this context I'm not really seeing any use case.
    - bbatha 5y ago
      At previous $work, I wrote a rails app that managed releases. On the app you could sign up for email notifications when your change was released. These went through the unix local email system. So yes there is very much a use case
      - lolinder 5y ago
        It's still a bit silly to tell every SaaS developer that they shouldn't validate that they have a normal-looking domain because some people's use cases call for sending emails to local addresses or to TLDs directly. If a developer needs to handle those cases, they know already, and they're in a vanishingly small minority.
Biganon 5y ago
I'm pretty sure the one guy behind ai. doesn't justify that you change your regex for him. Let's not be overly pedantic.
campital 5y ago
https://en.wikipedia.org/wiki/Top-level_domain#Dotless_domains https://en.wikipedia.org/wiki/Top-level_domain#Dotless_domai...
Supermancho 5y ago
> Domains ending with a dot are valid though, That doesn't mean you have to support their use. I have never seen a company support an email ending in a period and the world seems to continue along.

daurnimator 5y ago

I invite you to try my test suite at https://github.com/daurnimator/lpeg_patterns/blob/master/spec/email_spec.lua https://github.com/daurnimator/lpeg_patterns/blob/master/spe...

qwerty456127 5y ago

> containing upper unicode characters Are e-mail addresses case-sensitive? I would always lowercase&trim a string meant to represent an e-mail address (or a domain name) before doing anything else with it.

electroly 5y ago
The local-part before the @ can be case-sensitive, yes. I've never heard of a mail server that treats it as such, but the RFC says it's case sensitive.
- deleted 5y ago
  [deleted]
jeroenhd 5y ago
Not all uppercase characters have just one lowercase representation, and not all lowercase characters have an uppercase character. If you try to make the addresses case insensitive, you're bound to run into unnecessary complexities at some point. Email addresses aren't case insensitive in nature, but many commercial mail services (and misguided developers) assume they are.
hathawsh 5y ago
To be clear, by "upper" unicode characters I mean non-ASCII international characters, not uppercase characters. For example, 我買@屋企.香港 is now a valid email address. [1] 1. https://en.wikipedia.org/wiki/Email_address#Internationalization_examples https://en.wikipedia.org/wiki/Email_address#Internationaliza...

bobbylarrybobby 5y ago

I'm pretty sure email addresses are allowed to have multiple @'s. I believe everything after the first is (supposed to be) considered part of the domain.

chrismorgan 5y ago
Domain labels cannot contain @. If you support comments or quoted strings (e.g. (@)."@"@example) then you can get multiple at signs in an address, but in practice their only use these days is attacks where you confuse a badly-written server, which is part of why the web actively decided to disallow them.
- eadmund 5y ago
  > in practice their only use these days is attacks where you confuse a badly-written server Or, you know, if you actually want to use an at sign in the manner allowed by the RFCs. That's the point of standards: if something is allowed, then … it is allowed. Refusing to accept behaviour permitted by the standard is just broken.
  - chrismorgan 5y ago
    Usage is what matters. Standards documents only have value as long as people follow them; once enough people deviate, they cease to have meaning. This is thoroughly the case with a lot of stuff pertaining to email: if you want to parse arbitrary emails, for example, the relevant MIME RFCs are altogether insufficient, because too many people have done it incorrectly de jure, often to the point where it’s no longer incorrect de facto because everyone supports the deviation. (This is a deviation from spec in the direction of permission.) By hearsay alone, I say: comments and quoted strings in email addresses are, de facto, more or less dead. Comments especially, which were intended just as a compatibility measure for stuff from over forty years ago (when this was being developed organically, before there was any real spec). Most software whose direct business is email (that is, MUAs and MTAs) will more or less support them for historical reasons, but newer MUAs are likely not to support them in full (again especially comments), and I suspect the considerable majority of other software that deals in email addresses won’t support one or both of them. (This is a deviation from spec in the direction of restriction.)