Hacker News Reader

Comment by hathawsh | Hacker News Reader

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.

View on HN

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)

Good to know. I guess I'll simplify again. Besides, I wonder whether the expression is vulnerable to catastrophic backtracking.

> 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.

> You never want to send emails to local hosts

That's not entirely true, it depends on how your mailing infrastructure is set up.

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.

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

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.

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.

https://en.wikipedia.org/wiki/Top-level_domain#Dotless_domai...

> 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.

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

> 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.

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.

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.

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#Internationaliza...

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.

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.

> 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.

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.)

Reply on news.ycombinator.com