Stop Validating Email Addresses with Regex (2012) | Hacker News Reader

Stop Validating Email Addresses with Regex (2012)

davidcel.is

179 pointsgitgud215 comments

RFCs for email addresses are cool, but on the web we have our own standards!

https://html.spec.whatwg.org/multipage/input.html#valid-e-ma...

"This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here."

The regex is:

  /^[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])?)*$/

Every browser implements this regex for <input type="email">.

Chromium:

https://source.chromium.org/chromium/chromium/src/+/main:thi...

WebKit:

https://github.com/WebKit/WebKit/blob/0d7afc5a45c140c44497a8...

Yes, do verify email addresses by sending a confirmation link if you bind users to their email addresses, though. Don't confuse validation with verification.

I like your final sentence. Very to-the-point.

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.

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

What is the significance of [a-zA-Z0-9-]{0,61}? Some special limit on 61 characters?

Domain labels are limited to 63 bytes, with the [a-z..] before and after that makes 61 + 1 + 1 = 63.

Oh wow, that is awful.

If you really want to take validation seriously, why not add a human element to it, and not design one line of code to try to fix everything?

One of the biggest problems with email input is typos -- and there are some very common typos that could easily be accounted for with code. For example foo@gmail.co, foo@gmial.com, foo@comcast, etc.

It should be common, when these types of typos occur, to prompt the user to fix them. Unfortunately, this is quite rare.

Everytime I input my .me domain in one of those well intended websites I get nagged about maybe being wrong and wantint to use .de or whatever.

No, I know my email, thx, it's bein prefilled from auto-complete. Don't fucking tell my Im typing it wrong when 1. Its my email, and I'm not even typing

I have the same issues with my .name domain. Most of the reason I have a gmail address as well is for the sites that don't think "first@last.name" is a real address.

Related: I used to use me@<myname>.com but gave up because Gmail uses "Me" as the name when displaying a user's own email address and it was confusing people enormously because a thread would look like:

>>>Me wrote: >>Me wrote: >Me wrote: Me wrote:

That would imply that programmers care about users. I've never met a single programmer who cared what the user experience was like. Today they even brag about this, saying "I only want to care about my code!" I see it here on HN all the time, and I hear it in companies.

The other thing is overengineering. Spending a week to implement email validation? Maybe, if it is REALLY important and results in lost revenue.

Otherwise I don't know what common typos are. I would have to do research on that. Then I have popular local email providers where I may come up with typos. but then again, it is only in my region - I would have to get some list of popular email providers in every country. Come up with a way to update that list after few years when new email providers come out. Or maybe develop a solution that matches "close enough" entries in my pre-defined list.

UX effort could be spent in an area which is used more often than only once. If there is a library for that, yeah, then slap it in, UX has been upgraded in no time. And again, only if revenue is on the other side of consideration, the development effort pays off.

Revenue focus is not customer focus. You don't get a second chance at a first impression. The difference between a great company and a mediocre one is how much they care. Growth-obsessed companies only care about revenue and the 80% case. Long lasting companies build relationships, listen closely, and feel deeply.

Perhaps you are only looking for that kind of message. I see concern for users expresses by many devs here and hear it from other devs that I talk to. I can tell you that we have extensive discussions about the user experience whenever planning a new feature or change to and existing one. If our customers are not happy, that affects their use of our product, so of course we make this a priority. Besides, we also use it and we want it to work for anyone using it.

OP has shared a solution for typo fix in the closing remarks of the blog: https://github.com/mailcheck/mailcheck

> If you really want to take validation seriously, why not add a human element to it, and not design one line of code to try to fix everything?

human: a customer telling a clerk, "yes, it's really gmial dot com," and the two sharing a laugh and trading stories about funny email addys

human element: the customer curses their phone because the backend folks never tested the edge case of your helpful button for confirming the suspicious case of "gmial.com" and just keep rejecting it. Then, after your helpful chat bot kept autocorrecting their chat input to "gmail.com" they threw their phone on the ground so hard it broke.

Don't be a human element.

I have a .con in the db

In fact, doesn't 'RFC' imply that it isn't a standard?

A pragmatic, domain-specific spec beats that.

edit: there's more nuance than that. Some RFCs are standards. 2822 is 'Category: Standards Track', so is a standard if referred to by its STD number? I can't find what its STD number is.

This is the sane approach. Nobody uses the bizarre address formats with quoted strings and embedded comments and whatnot. There are included in the RFC because of backwards compatibility with legacy email systems from before SMTP.

Quoted strings are actually used in the real world, though they're certainly not common.

Shitty front ends are definitely putting an end to that, though.

I'd say that's for the better.

One important aspect of this that I often see people forgetting is that this check is designed for working with ASCII, but the domain name at least can be non-ASCII. User interfaces should remember to support IDN in domain labels and convert it to punycode before validating, and if you store A-labels (which you probably do) then convert it back to IDN form when presenting it to users.

(Alas, <input type=email> still doesn’t support non-ASCII in the local part, which isn’t supported everywhere but is, I believe, fairly widely supported now. See https://github.com/whatwg/html/issues/4562 plus https://en.wikipedia.org/wiki/Email_address_internationaliza... for a little more background on what it is.)

I thought they've rolled back most of this because it made phishing domains indistinguishable from the real ones?

I used an-emoji.my.domain for a while until chrome changed it back to punycode

I erred slightly in what I wrote there; I said IDN form for user display, but should have said IDNA form, which is the set of restrictions to mitigate those hazards. That will allow things like उदाहरण.example, while leaving emoji as xn--n3h.example since they’re not valid in IDNA. See also https://en.wikipedia.org/wiki/Internationalized_domain_name and https://en.wikipedia.org/wiki/Emoji_domain.

Actually, I’ve got to add another note because my memory and experience was insufficient here: see also https://en.wikipedia.org/wiki/IDN_homograph_attack#Client-si... for descriptions of what further restrictions browsers do, with the most notable additional filter being disallowing mixing scripts. This is something that would be nice to formalise in some way, though I don’t know of any venue suitable for the task.

The only way to validate an email is to send a message to the email address. Validating that it fits the rfc is pointless, because a) its very easy to create an email that is both false and meets the rfc, b) email provider might bypass the rfc and the email would still be working.

To validate user input, I use that: /^[^@]+@[^.]+\..+$/. It's doesn't tell me if the email is semantically correct per the rfc because I'm not running an rfc correctness validation service. What I want is to make sure that users didn't input their name in the email field. This tells me if it ressembles an email

It isn’t pointless. It is fast feedback for typos and form validation

But the proof of the validation is in the sending. If it’s important I send a validation email

There is some value in reducing the number of bad emails sent out, because email providers don't like it if you send large numbers of emails to bad addresses. So if you can help someone get their email right the first time, it's worthwhile, as long as the mechanism you use isn't overbearing.

The parent's regular expression covers the most egregious typos without making any assumptions about domain names or tlds. If you wanted to help out with common typos you could add additional logic to specifically check for "*@gmial.com" or other permutations of the common domains. If you wanted to get really fancy, you could even run it by an edit distance function against the common domains and warn if they're close to a common one but not quite there.

Most typos, however, are likely to be in the first part, not in the domain. The only real way to validate against those is to try the address and see.

It misses the very common mistake of typing a comma instead of a dot.

Otherwise, yeah, most people would be better served by a library that detects domain typos like https://github.com/mailcheck/mailcheck than spending time on regexes.

A small subset of typos. bob@mail.com and bob@mial.com will pass the same validation rules.

A regex won't catch typos. Send an email, or if you really want force to enter twice. The rfc is both so permissive and generic that pretty much anything will pass it, while at the same time it is very hard to test it, so you might block legitimate ones. MSFT for example allows you to use your personal email as a MSFT account. If you username is less than 3 letters some of the validation they do in some of the subsystems will reject it as invalid that they even validated with a confirmation email. I can't count the number of systems which reject + in a username or a subdomain in the host. Truly you're just making it harder for the users and for yourself.

It's the difference between type checking and business logic validation.

E.g., Type check that the user's name is a String and then let the database/business-logic yell at you when it's not unique.

In this case, checking that an email address input is "shaped" like 'not-empty@not-empty' is the "type check", and then actually sending an email is the only way for your business logic to know if it's actually valid.

You actually should at least use regex to check some basic things. Like "@" "." or even just disallowed characters.

As someone who sends a LOT of email for customers every week, a big percentage of our problem is incorrectly formatted emails. So we just don't even let them in these days.

People are forgetting that for services that have to send email it costs dearly to bounce.

Bounces decrease the quality of your list and you can get penalized by your email provider. By letting in stupid sh*t, you just are compromising yourself. So some simple regex that gets rid of the most egregious stuff is worth it.

Please don't check for a full-stop/period. It excludes those who have their email address directly on a TLD.

Is that an existing cohort? I'm not saying it isn't, I've just not run across them.

Probably not. http://ai./ has a website, but no emails AFAIK

https://mail.gnome.org/archives/evolution-list/2002-January/...

Huh, looks like n@ai. still exists, I wonder if it's in use anymore.

20 years ago.

No it doesn't. Those require a dot at the end. Without a dot, it's a hostname not a TLD.

https://mail.gnome.org/archives/evolution-list/2002-January/...

Without a dot it won't always use the TLD.

  easrng@easrng-laptop:~$ echo -e "127.0.0.1\tai" | sudo tee -a /etc/hosts
  127.0.0.1       ai
  easrng@easrng-laptop:~$ ping ai
  PING ai (127.0.0.1) 56(84) bytes of data.
  ^C
  easrng@easrng-laptop:~$ ping ai.
  PING ai (209.59.119.34) 56(84) bytes of data.
  ^C

You're right. I did some experiments too after your first reply. It's definitely inconsistent depending on what software you are using (as some software now bypasses your system resolver and uses HTTP DNS etc). I've known people who had email addresses on TLDs and they never had any problem receiving email (without using a final dot), so I'm not sure how the MX record is being resolved or how the SMTP connection is being made. It's very possible that the mail daemon is automatically adding a dot to the end of every hostname.

Technically, without a dot at the end any domain name is a partially qualified domain name. Technically, 'gmail.com' should mean 'gmail.com.local.search.domain.' if your local search domain/zone is "local.search.domain."

I think the case you are really making is for using the string validation (regex) to knock out clear or even obvious mistakes, as opposed to using a regex that everyone has to pass to proceed.

Yes.

Validate emails in a manner that is representative of the typical use of your service.

If it’s a specialist email processing tool, then you should probably follow an RFC.

If it’s a dating app, you can probably just use a regex that covers common cases to help users avoid typos.

I think the decision is similar to the one picking how modern are the browsers you are going to support. It’s a trade-off. That’s my take on it, don’t have a cow, man.

You will want to check ownership by sending a verification email anyway. If you want to avoid typos, show a "are you sure... yes/no" warning, there is no need to block anybody.

Typos will overwhelmingly lead to valid-looking addresses anyway.

I usually just validate that there’s an “@” character. It prevents the most obvious typos like a blank field, or information entered in the wrong field.

You’re right that you can’t prevent someone from typing their address incorrectly, but you can make sure they didn’t put in their phone number or their first name by mistake

Mailgun has an API endpoint that works pretty well. If you enter "foo@gnail.con", it suggests "foo@gmail.com".

It's overkill for an HN registration form, where if I type my email wrong, I can just re-register, but for checkout forms it can be worth putting in a little extra validation.

I agree, but there are all kinds of scenarios where you might need to simply answer a question - “is this an email address, and does it look valid?”.

I needed to do just that once - I was given a flat file with some bulk export data that came from some other system that I had no exposure to and needed to clean up contact data by figuring out what was what, separating names from phone numbers, from postal addresses, from emails, etc. It just needed some rate of success, not to be perfect.

Lets not assume that we always know what people are trying to do and what is the best way to do it. Devil is in the details.

Extraction is not validation. I generally agree with you, but your previous message (about "a dating app") left little to assumption.

You might want “clean” or “normal” addresses too (for whatever reason). For example, disallowing “+” would just give you the canonical email instead of one that risks being tagged with a unique ID revealing who leaked it.

Being too generous in the early input validation regex (e.g just check for non empty and containing one @) risks making registrations fail and customers not returning. This seems like a much bigger risk than locking anyone out who has a weird email Even a character beyond [a-z0-9-_] or domain without tld is probably worth rejecting.

`+` is a legal part of the mailbox name everywhere but gmail (and gmail clones). Broken "checks" like these are exactly what the simple validation is avoiding.

If people who use '+' on purpose are fewer than those who type it in error (who type bobsmith+ when they meant bobsmith0, then it might not be a good idea.

The entire argument I was trying to make was that what constitutes a "legal email address" is not always what you want to validate. That some providers allow using '+' isn't as important as the number of users that actually do. If some nontrivial number of users use + on purpose, then don't reject them.

Why do you believe that? What do you gain by rejecting '+', no matter how few people need it to work?

You should also reject `z` in emails. The number of users who type this accidentally no doubt greatly exceeds the number who actually have that letter in their email address.

I'm not sure there are even many SMTP servers that fully follow the RFC. Embedded comments in an email address is a weird feature.

This won't be popular, but:

1. An experienced dev just killed 54k stars on GitHub due to pressing a button in an auto-pilot mode. Do you think a Joe High who wants to give you $100 won't ever type '2' instead of '@'? What about an old lady? Or someone with physical difficulties? Have you personally ever made a typo in an email?

2. That code in the article is not color highlighted (rainbowed for Regex) or formatted properly. If I write something in any language in one line without highlighting — it'd look unreadable as well.

3. A Regex for this specific purpose is write-once-and-forget. You won't need to edit it for 20 years.

4. Regex — for practical tasks — is way easier than it's being painted. Not easy — just not as hard as some suggest.

5. I'm not a Regex fanboy (nobody is).

Sure, but the most common typos would just result in a wrong address which is still syntactically valid. That is why the address should be verified by sending an actual mail for important stuff. This is also the only way to protect against fake addresses, since anyone can come up with a fake address which is still syntactically valid.

I do like to check for '@' to enure the user have not entered their name or something by mistake, but beyond that the syntactic validation does not provide any value.

Agreed. And while I wouldn't attempt creating a regex for email addresses -- if I really felt I needed that, I think that's what libraries are for, not my job -- I have used plenty of regexes in useful and successful ways. I wanted to really add to your "you won't need to edit it for 20 years" comment that the regex should also be anchored with a unit test, that demonstrates the usages you designed for (and maybe a few negative tests to show what you specifically didn't intend to solve).

Simple validation is easy enough to implement and will cover 99% of cases. For the rest you use verification, have the user activate their account before doing anything.

Which is a pet peeve of mine; I've got an older e-mail address that probably ended up on some list, now there's people from Thailand and the UAE registering accounts using that e-mail address. Now while my account is still secure (2FA, long password, the works), it doesn't stop people from using it. Services like this one webshop and Deezer and probably a few others do not wait for e-mail verification before allowing users to place orders or use their service, or at least the free trial part of it.

> 5. I'm not a Regex fanboy (nobody is).

I am :)

Me, too! They can be complex or wrong, but just as often they're a decently simple way that every programmer understands to check something.

>You won't need to edit it for 20 years

I won't bet my life on it but probably some other sucker will have to fix it. This happened to me where I found a regex that was validating urls was incorrect after urls were allowed to contain unicode stuff (I do not remember the details just that we had an url from a customer that contained arabic looking characters)

IMO the language standard library should include this stuff of validating stuff to avoid developers copy pasting dubious quality regex from Stack Overflow

Can't upvote this enough.

There simply is no need to check the email addr provided by the user. Send the mail, if it bounces, the user has only himself to blame. What if I don't want them to go through the hassle of an activation link? Then I don't bother with an email account in the sign-up process in the first place. If they want a passwd reset method, they can later provide an email in their settings page, if that isn't valid, well, tough luck.

Bouncing usually requires money

So does sending the verification email, so it's a wash. Thinking about implementing email validation + verification is a great opportunity for developers to do two things:

1) Consider if you really even need to verify that email address. Why are you collecting email in the first place, why do you need it? HN is a great example of this - email totally optional, if you forget your password it's on you. Lot of online services going in the wrong direction with requiring a phone number.

2) Trust the user. Okay to give them nice nudges ("you probably meant gmail.com and not gmail.co") but if I really did mean gmail.co, let me through if I insist.

Don't throw up a garbled mess of a Regex[0] that only serves to frustrate me when I try to sign up with my vanity email. I'll abandon the sign-up entirely.

[0]: https://stackoverflow.com/questions/20771794/mailrfc822addre...

The most underrated crypto thing that people don't discuss enough, is that i don't need an email account to interact with web3 apps, i just sign in with metamask. if I could do it for every single app around that would be great.

What's wrong with a username and password?

not secure enough, prone to easy abuse/workarounds.

To answer this, ask why you use an SSH key to authenticate with all of your servers.

Easy to forget login, easy to forget passwd, easy to forget what passwd is attached to some login. Not to mention that nowadays most services ask some second and third factors like email which has 2 passwds, phone which may be lost, docs which may be unwanted to demonstrate. Modern cryptography may solve it if webmasters really want it (but for some reason they prefer to collect as much as possible).

> Easy to forget login, easy to forget passwd, easy to forget what passwd is attached to some login.

All solved by a password manager.

And being bond to some database? That is... not for everyone.

Password manager is good if it is planned to share all my passwords after my death with my family, for not gifting my funds to some random guys. In every other cases it sucks like Sasha Grey (from my lifestyle's point of view which involves heavy use of random devices most of them even does not support any passwd mngr).

> In every other cases it sucks

It doesn't for basically everything I do, and I have a lot of systems, subscriptions, and profiles to worry about.

> random devices most of them even does not support any passwd mngr

In the simplest case, 2 things are needed to support a password manager: Network access, and copy-paste.

> In the simplest case, 2 things are needed to support a password manager: Network access, and copy-paste.

All of my mobile devices doesn't really support JS so I can not even input my HN's password to there without a PC.

Also I do not believe all of my e-mails which has some accounts with some values on it are still working. At least one time I had to re-register e-mail exactly as previous to withdraw some of my funds which were untouchable for few years :-) So the biggest part of problem is not on user's sides of wire and I have already tired to struggle to formulate such a simple thing using such a lot of sentences.

network access itself is not necessary foe using various password managers, though of course for the majority of uae cases you'll require it anyway. But if you e.g. have a journal that is encrypted, you only need copy-paste.

These all sound like convenience factors. I don't see why my identity with one provider has to be tied with my identity from another provider at all. Having a crypto wallet (for this purpose) is just certificates with extra steps (quite literally, as it's cryptography).

If only browsers had a public/private keychain built in to sign and encrypt messages. Authenticating = sign a message with your private key.

Browsers have mutual TLS auth if you want that type of authentication. The UX is mediocre and MANY tracking websites will ask you to sign in (either out of incompetence or malice) in your regular browsing, but it's definitely possible to use such a system.

Nobody is accepting random self-signed certificates, of course, usually they need to be signed by a CA belonging to the party you're authenticating to, but there's no technical reason why you can't use a random certificate to authenticate with a website, or even modify your browser to add a quick and easy button to generate them on the fly.

Browser vendors have stopped caring about this type of auth and are focusing more on webauthn, which stores a cryptographic token in your device's secure storage (if available) or on the file system. When browsing from a phone, this means it's essentially "sign in with your fingerprint" for websites, which is really cool! You can't easily back those tokens up, though, so you still need something like a recovery email if you don't want your users to lose their accounts when they drop their phones too hard.

Why is that better than signing in with google or apple?

You don't need crypto for that, though, client side certificates have existed for such use cases for decades now. Companies aren't using them so nobody knows about them and therefore browser vendors don't care about the UX and therefore nobody wants to use them, but that cycle will happen for as long as people don't implement such login methods.

If there was a way for end users to sync webauthn logins, we'd solve this problem without ever resorting to any kind of blockchain whatsoever.

Don’t most emailing services heavily penalize a high bounce rate, including banning of the commercial account if it goes on for too long ?

(which as far as I understand is also to protect the emailing service from getting blocked itself)

I can assure you that this would end up with far more problems than it will solve.

I run an online store, people miss entering their email address is one of the largest causes of customers contacting support, and they regularly jump to being angry accusing us of being incompetent or worse.

I would take the 0.001% of people who may have an email incompatible with a regex being frustrated (which will happen to them all the time) over the 10% who screw up entering their address.

We even have code that looks for common typos and prompt the users to double check them. Somehow they still make those mistakes.

You can obviously warn the user, but it shouldn't be a strict validation. That's half of the point. It's probably a mistake if someone typed gamil.com instead of gmail.com, but it's not a mistake if someone typed pm.me (or something punycode).

What's much more important than validating the syntax of the e-mail is not to let your service be turned into a relay for targeting e-mail addresses of third parties with "backscatter".

Don't put up a web page where any visitor can put in an e-mail address, to which you send something, without any safeguards: like not sending to the same e-mail address more than just several times in a 24 hour period or something.

Have Captches or or something to reduce the bots. Proof of work. Whatever.

It may be wise to validate not for valid e-mail address syntax, but for certain invalid e-mail addresses to which you shouldn't send.

For instance, would any legitimate user be subscribing with an e-mail address of postmaster@example.com? It seems it would be worth it to have a database of patterns of at least some well known mailing list addresses. Certain domains are almost certainly mailing lists; e.g. anything@vger.kernel.org is probably a list; don't send to it.

Process bounces.

I got some like that just last week. They were using a public sales quote request contact form, filling it with a bunch of random characters except for a valid email address and the name, which was something like "♥ Martha wants to meet you! Click http://... ♥"

It's a massive issue. It's not only spam, it also enables malware distribution and e-mail bombs (flood of mail to cause DoS or to hide some other letters).

It is mostly because proper defenses against such abuse aren't built into software allowing such forms (or cost money). Wordpress form plugins are one such widespread bad example.

> Send the mail, if it bounces, the user has only himself to blame.

Some products don’t want to let users fail so easily. Especially if they spent good money to get you to the point of signing up.

I would like to agree, but sending an email that bounces will negatively impact your email reputation and thus your deliverability.

I work at a large web company. We ran a test around removing email validation and we had about 20% of users typo their emails when signing up. Simple things like not putting the period before com like "john@gmailcom". It resulted in customers basically creating accounts they couldn't get back to which was a bad user experience and loss of revenue for us.

Based on our testing, email validation mostly served to prevent these basic typos.

> if it bounces, the user has only himself to blame

So your system always makes the least effort and pushes the blame to users. Great.

How about just even do a minimal check that is /.@./ so that the basic format is at least there or if you'd take 10 minutes to look around, you'll find the regex browsers are using and just steal it and be done with it, so most of the malformed inputs are warned to the user before the user realizes the confirmation email isn't arriving minutes (or days) later and possibly lose the conversion right there.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

I wrote an email validating regex at one point. It checked that there was exactly one @ sign in the address, which was neither the first nor last character. Seemed like a pretty good compromise to me.

Still incorrect. Valid email addresses can contain multiple '@'s as long as all but one are quoted.

Yes but why would you do this other than to be extremely smug when forms fail for you?

And we lost the 0.00001% of the market that has such an email address.

Says who? I don't consider that address valid.

1) simple regex to rule out the common typos such as 2 or 0 @, no period in the domain name, etc. I don't care about people whose domain name consists of a TLD only. Bring your nerdiness somewhere else, every other service is already rejecting your exotic e-mail address already anyway. Same for spaces in the local part of the address, etc.

2) if second level domain not in list of famous second level domains, AND levenschtein distance is small with a domain on the list (typically gmial, oultook, yhaoo,...), display a huge warning. Don't refuse if the user insists it's correct, but show a huge and red warning that blinks. Same with the TLD to detect "cmo", "ogr", "inof" etc.

3) Maybe send a validation email, now that you've ruled out a big number of potential mistakes. You won't get that many bounces. Or don't send the email if you don't need to!

I fail to imagine a scenario that wouldn't be neatly covered by this 3-step process.

> I don't care about people whose domain name consists of a TLD only.

I’ve never understood this, but heard it often from developers and product owners in the industry. “I don’t care about the small number of users who X” where accommodating X is essentially free. Or worse: deliberately taking the eng time to reject users X where accepting takes no work!

Especially in a business context where users X are trying to hand the business money.

I had a tech lead once who say we should reject non-ASCII characters in user input “because they are an edge case.” Nothing in the rest of the data flow or database storage required ASCII characters and it took eng effort to filter them out. Boggles the mind sometimes.

Accomodating an individual X is essentially free. Having a policy of accommodating all the X's that turn up is not free because those small individual expenditures add up.

I think an initial test with regex is valid. But you should do a proper email validation link.

That being said, you need to be very careful with what regex validation you are doing. I still use an apple "@me.com" email. Somewhere there is a commonly used library (or commonly used regex copied from stack overflow) that seems to fail because my domain is short. I have had a number of times that I have been unable to get emails because a system flagged it as invalid.

Getting through to support or trying to change my email is always a nightmare in these situations.

So be careful with your assumptions!

Similar experience for me. Many online forms fail to accept any email extension that isn't ".com", ".net", ".edu" or ".org". I'm surprised, because developers should know better that there are many more extensions beyond these four. Here is a full list of domain extensions available: https://www.name.com/domains . Let's just say one of these is registered and used as my email.

I have found two ways of getting around this issue.

1) Continue registration for a new site using a temporary email. Once logged in, I find I am often allowed to change the email to whatever I want within my user settings. 2) Contact support and request they updated it for me manually.

These two work arounds don't always work. But more often than not they do.

Here is the actual, official, list of TLDs:

https://www.iana.org/domains/root/db

Thank you. I figured there was a more official list out there.

I have the same problem on about 10% of sites.

I had a big ecommerce site go into their DB the other day and update from my temp email to my real. Now my profile is fucked because it validates the email address on the page load.

Does anyone on HN have any of these "surprising" email addresses that most people and developers do not expect?

How does it work with common e-mail clients? How do people react when you show/tell them your email?

I have a domain that uses non-ascii characters, and while I can receive emails on that domain, hosted by Fastmail, Fastmail clients refuses to _send_ emails to that domain (I can, if I type the domain as Punycode).

I can't type one of my email address on HN as it has emojis in the hostname. It works great with Fastmail. It gets problematic when I use emojis in the mailbox name as well. At lot of hosts won't allow that.

You can see the email address on the front page if I paste the punycode web address on here:

https://xn--bp8hgh.to/

Messing with emoji taught me how absolutely atrocious unicode support among email servers is. Gmail supports it, but even modern versions of postfix require special compilation flags to enable SMTPUTF8.

While emoji aren't a use case you'll get many managers to care about, there are plenty of unicode characters that can. Email addresses using foreign script, for one, or even just characters like åäáà, not uncommon in European names, might convince people to consider enabling such features.

Sadly, the process of enabling support for such characters is much harder than it should and I've got to admit they my mail infrastructure also can't handle these types of email addresses. Modern MS Exchange servers seem to have finally implemented support, though, so perhaps we may see more support for it in the future!

I think postfix's DB drivers were also still latin-1 only, if I'm not misremembering I had to mojibake what I wanted it to pick up.

Though UTF-8 is not the only thing atrocious with e-mail stacks, there's so much maintained-but-not-really non-standard software that a lot of people rely on.

To end on a positive note, e-mail hosts are starting to demand SPF to accept mail.

I do and like many other HN users, when websites refuse to accept my email, I simply don't use their service. I haven't noticed any decrease in my quality of life - in fact, being able to use my email freely is invigorating and gives me a sense of worth in this corporate controlled internet.

I have my own domain and a catch-all setup, so when I sign up for a service, it's the-service-name@my-domain-name.com, if I give someone my email address, it's their-name@my-domain-name.com

It makes it easy for me to keep track of who is sending me what + who is sharing my email with third parties, but definitely confuses some people.

Samsung is particularly annoying about this. You can't sign up for an account with "Samsung" in the user portion. They'll straight up block samsung@yourdomain.net, so I've resorted to misspelling their name in the email address and they seem perfectly fine with that.

I've been using sam.sung@domain for them. First time I've come across this block in years of using this method.

> Does anyone on HN have any of these "surprising" email addresses that most people and developers do not expect?

I do

> How does it work with common e-mail clients?

Perfectly

> How do people react when you show/tell them your email?

With confusion, so it requires some gentle insistence that I know my own email address.

PLEASE, FOR THE LOVE OF GOD, can all of you who write email validation not include a whitelist of TLDs that you allow. THIS IS KILLING ME.

My primary email addresses are on two TLDs, one of which has been around for 24 years, the other for seven years, but about 10% of sites I try to register on refuse to accept them, saying that they are not valid. They clearly have not updated some internal whitelist since these TLDs were added.

I just had one major ecommerce go into their DB and update my address. This was a bad idea because now my profile page has an error and I can't change anything else.

STOP THIS. JUST STOP.

Obviously, they aren’t going to stop. Why wouldn’t you just give up and get another email address and set up forwarding? Life is too short to yell at clouds all day.

I wish they would just modify the standard to not allow "Look at all these spaces!"@example.com and such. Many email systems already don't accept it (e.g. gmail doesn't, probably others but I didn't test) so the actual practical value is small. There's a whole bunch of stuff in there that no one uses and just makes things harder than they need to be.

I've been programming for 25 years. I've been reading this same article repeated over and over again for 25 years too. Clearly it's not working.

It's not working, but not because the standard says you must support a much more lax format. It's not working because some people are writing bad code, that code does not only fail for spaces between quotes. It fails when more than 50% of the world tries to use their native alphabet - when using UTF-8.

It's not the standard's fault that people implementing are not following the old adage of implementing standards: "Be strict in what you give, be lenient in what you accept."

Considering how there's really not a tremendous amount of variety in what e-mail software people use, it boils down to those maintainers' stubbornness. If you dig trough old mailing list threads and issue tracker tickets, the ossification becomes quite visible.

I think the point of the article is that this seems like it would be an easy problem to solve, but it is not.

Lots of commenters insisting that they need to validate somehow. If you have a need to validate, use a good email validation library. Better consistency throughout your app, and someone else has figured out the hardest stuff.

Stop validating emails. But if you can’t stop, at least stop rolling your own regex on the fly to do it. Use a good library instead.

What's even worse is that a lot of people think that it is a great idea to check the TLD against the set of existing TLDs. Of course, nobody gets such a whitelist right or cares to update it if new TLDs are created. From experience I can say that having an e-mail address with a not so popular and rather new gTLD is an absolute nightmare. We had to roll out aliases with "normal" TLDs to combat this.

That's because almost as soon as a new TLD becomes available spammers start using it as the from address in emails. For probably 99.999% of people the only email they will ever see with such a from address is spam. Just automatically marking all mail from those domains as spam turns out to have such a ridiculously small false positive rate and eliminates so much spam that it is worth it for many people.

That does mean that in practice it is probably best to consider most new TLDs as web-only. Use them in URLs but have @com, @net, or @org email addresses for anything where you want outgoing mail to get through.

When I was running my own mail system, I eventually ended up with all of the following TLDs going straight to a spam folder:

accountant bid christmas click club cricket date download faith gdn gq help info link loan men party press pro racing review science site space stream team top trade uno webcam website win work xyz zone

Every TLD is full of spammers. Most spam I receive comes from com/net/org domains, but blocking those is silly. Hell, I barely receive real email from Gmail and Outlook domains in my personal server, I'm pretty sure my spam algorithm is starting to get a bias against those domains at this point.

When you're dealing with signups for a service, there's absolutely no reason to refuse a working email address.

Ten-year-old article. Everyone still uses regexes, including browsers. World has not ended, I rest my case.

Some negligible fraction of pathological email addresses will get rejected by imperfect regular expressions. I’ve tested multiple email validation regexes against huge databases of actual emails and found they all validate.

As a former email professional this hurts bad...

Why validate? JusT SpAm!? It's quasi-legal. Bounce rate? Who cares!! Not like we are monitoring ip reputation anyway amirite?

One of the best validation techniques I heard was check for an "@" symbol and if they have one the call it good.

You are doing God's work, my friend.

Most internet systems can also assume there will be at least one dot following the @ symbol and at least two characters after that. Something intended for us on internal domains of course can't many assumptions.

The two character requirements can trip up foreign TLDs if the input is encoded as unicode (but everyone knows you're supposed to translate the domain to IDN before running validation, right? Right??) so I wouldn't even use that. There don't seem to be any TLDs that are only one character long in their encoded form, but I can easily see Chinese or Japanese TLDs leveraging their extensive character set to keep the TLD part of the domain short. As long as there's something behind the @ before a period, it's probably fine for an external email address.

Missing a period can cause problems, because without a period or a TLD at the end, your mail service might try to send email to internal servers in your network. Send mail to a@b from server c.com and you might end up sending email to a@b.c.com instead. Not checking for a period in the domain part can therefore cause some pretty weird behaviour.

If the email ends in an external domain, there's a period. If the email is intended for an internal host without a full domain name, the period should be at the very end of the address, turning it into a proper hostname.

It's easy for people to type gmailcom and if you're using dot less domains in your network infrastructure you probably know about these hacks anyway. I don't think checking for a dot will break anything, even in the spec, except for something@[IPv6 address] but IP address emails are practically unused in real life anyway.

I've been seeing this kind of argument from the mid-levels on my current team, paraphrased like this: "I am having a hard time understanding this, therefore it needs to change."

That can be a valid complaint as long as it's not about the logic or rules themselves, but how they're expressed in the code. Code that your team members can't work on is a liability.

Agreed.

I see complexity as kind of a mass, and our job is in part to reduce it as far as possible.

Like mass, you can shuffle complexity around, or add more, or discover unexpected ways to reduce it, but there is no way to reduce it below the problem's lower bound.

Sometimes, the solution is as simple as it's going to get, and it's still complicated. State management is a good example.

I'm more referring to that situation.

This article's headline is an example of the argument I mean. If not using Regex is the proposal for reducing complexity, it's not going to reduce complexity.

> Sometimes, the solution is as simple as it's going to get, and it's still complicated. State management is a good example. I'm more referring to that situation.

That's fair. There is definitely irreducible, or essential complexity that we have to deal with.

I wish validating emails through sending was more common. I have early days Gmail account based on a name. For some reason there are many people out there who put my email on their accounts. Great when I got free Disney+ for a few months because someone signed up with my email. Less fun when ovia health won't stop sending me fertility tracking information about a stranger because they put my email down and ovia didn't think it important to validate.

2012? And it seems so little has changed. Several times per month I am told by websites that my supplied email isn't valid even though it can receive email. All because it is using one of the "new" top level domains ".email" and has been for 6+ years now.

The breakdown of websites this happens most on are large corporate websites or very small online shops using some no-name shopping cart software.

This is almost entirely because a lot of websites stupidly reject +. A few stupidly reject - or _ too. That's easy to fix while still using regex validation.

There might be some people who run their own webservers and use more exotic addresses (local parts), but 100% of them also have more normal email address they use for random website signups. If all websites would make sure to accept + in local parts, and - and _ everywhere, there wouldn't be enough people angry at the situation for articles like this to be written and generate any traction at all.

Sending emails might cost a fraction of a cent if you use a 3rd party service. When it's not free, regex validation can save money. There's a potentially valid reason to do it.

Or maybe the people writing the website's javascript are just control freaks. So what? That's not a reason to argue for all websites to stop doing regex email address validation.

Allow + in the local part, along with - and _ everywhere. That's all you have to do. You don't have to give up regex validation and try to send every typo'd email address that a visitor might enter on a form.

I recently launched a webpage without validation on the email field. 90% of the rows created in the database were not emails.

I understand the point about not maintaining complex regex, but I just used an npm package that maintains and updates validation regexs with web standards. Besides any remaining left-pad jokes still standing, I don’t see why I would eschew this solution for any future forms?

Not saying you shouldn't keep doing what works for you but: If visitors knowingly put invalid e-mail addresses 1) do you really need an e-mail address from them, rather than making the field optional? 2) If so, validation should be done by sending an e-mail with a validation link either way.

As others pointed out, for a sanity-check something like /.+@.+/ should be good enough.

If you are concerned with the maintainability of RegEx (i.e. "Now you have 2 problems"), do it via simple string parsing. It's more code, but it's readable by mere mortals.

If it has an @ sign, split at the @ sign.

If either string has a space or other invalid character, it's invalid. Yes, there are more invalid characters for the domain than the username (I would make the case the username should just be whitespace chars, and the @ sign).

If the second string doesn't have a dot in it, it's invalid.

Split the second string by dot. If the last string of that array is not a valid TLD, it's invalid. (I realize new TLD's are popping up these days, so this step may not be strictly needed)

Not being too strict is in your interest here. You avoid too many email bounces by allowing some things which may be bad but allowed in some email providers but not others. It's a case of "Perfect is the enemy of good enough".

> If either string has a space or other invalid character, it's invalid

Nope, could have a quoted string which can contain whitespace.

  addr-spec       =   local-part "@" domain
  local-part      =   dot-atom / quoted-string / obs-local-part

  qtext           =   %d33 /             ; Printable US-ASCII
                       %d35-91 /          ;  characters not including
                       %d93-126 /         ;  "\" or the quote character
                       obs-qtext

  qcontent        =   qtext / quoted-pair

  quoted-string   =   [CFWS]
                       DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                       [CFWS]

> If the second string doesn't have a dot in it, it's invalid.

Nope, domain names dont require a dot.

  <domain> ::= <subdomain> | " "
  <subdomain> ::= <label> | <subdomain> "." <label>

> Split the second string by dot. If the last string of that array is not a valid TLD, it's invalid. (I realize new TLD's are popping up these days, so this step may not be strictly needed)

Doesnt need to be a "valid TLD" to be a valid domain

Sure. Fine. Skip that part then.

The larger point I was trying to make still stands.

Sorry, I added more issues as I copied the corresponding snippets from the RFC.

Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start.

> Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start.

This is actually the whole point of what I wrote. Making the maintenance of the code low-effort, and having it be more permissive (i.e. less valid) and relying for the corner cases to be taken care of via email bounce.

See: explainer on "Now you have 2 problems"

https://arstechnica.com/information-technology/2014/05/what-...

If you read this whole comment thread you can see where this leads: increasingly complex regex in order to handle all the corner cases. Forget the corner cases, just make it "good enough" and relegate those corner cases to email bounce.

Now - I don't have a case study to prove that this way of going about it is more valid than the strict regex validation you're suggesting. But I wanted to represent it as a middle ground between "just rely on email bounce" and "write a big long regex".

I like the first comment on that article:

  Some people, when trying to explain something, think "I know, I'll use a Jamie Zawinski quote." Now they have two things to explain.

Regular expressions are validators of user input. Verification of user inputs are very important because they provide error messages, if you just send an email and it fails it can be for many reasons:

1. The user made a mistake when typing the email.

2. Some internal server failed to send the email.

Without an error, the user will never know what went wrong.

I think normalising emails is equally important these days, esp if you are offering any sort of free trial on your website (that incurs a cost to the seller) as it has become quite common for freeloaders to create dozens of accounts using the dots and plus signs just to abuse the free services.

The last time I implemented something like this we used a little library to check for typos on common domains and gave users a chance to correct on the front end before submitting. It significantly cut down the frequency of bad email addresses.

All of the other stuff is important too, but the most common issue is going to be someone tying "gnail" instead of "gmail", not having an obscure domain.

On a related note, I have mylastname@gmail.com and I receive emails from other people with my last name several times every week. I am almost certain they mean to type [firstinitial]mylastname@gmail.com but miss that first character. That's my working theory anyway. I've had to intervene multiple times when getting sent important medical emails for a different person with my same last name.

This is a very bad idea, it will make your customers and support team unhappy.

It’s is one of those “technically” vs “practicality” things, not using a regex will cause you more customer support problems than solve.

I run an online store, typoed email addresses are one of the top causes of customers contacting support. In 10 years we have never had a customer contact us to complain their “valid” email address won’t be excepted on our site. If we were to remove the regex from the validation and “just try to send an email” as suggested it would create so much more work for our support team.

You should also implement some “soft” validation looking for common typos, although people still somehow make those mistakes. I’m convinced that some people have types in their autocomplete address book.

I appreciate the idea here but generally you set a non perfect regex expression and just roll on with whatever other verification there is (send email). Well I don’t but if you did I don’t see much harm.

I won’t ask people to type the email twice, that’s just annoying.

And it becomes super annoying when you can't paste into the second field. Had to implement this once - should have rage quit immediately.

Agreed, also anything that defeats a password manager is a red flag for me. I've seen sites that break a password manager's autofill AND disallow pasting a password. It's like they want me to use a bad password.

All forms should have input validation before you do things like try and store it or god forbid process it inside code. Instead of regex a better move might be using a forms validation library that works well and is actively maintained.

Report as spam, it starts to hurt the sender in the end.

Here’s the regex you should use:

    .+@.+\..+

Works every time 100% of the time.

Haha I like the other poster dude's suggestion of just letting it through if you see an @ symbol. Wouldn't yours work with potentially too many weird character sets? probably language/runtime dependent

Those character sets should work, the standards allow it. Your software should auto-punycode the domain part anyways.

That dude gets it!

Famously won't work for n@ai, either with or without the trailing period to ensure global name resolution. The .ai is one of a rare few ccTLDs that have (or had) top-level MX and A records.

https://mail.gnome.org/archives/evolution-list/2002-January/...

2unusual4me

Just chiming in on about the ‘local-part’ of the email address.

I wrote a short (but incomplete) research comparing mail servers (MTAs) and their handling of local-part in my ongoing effort to reduce spam and to tackle who is leaking my email address.

‘Local-part’ is the part of the email that is between your account name and the ‘@‘ symbol. For some MTAs, it CAN be the part before your account name.

https://egbert.net/blog/articles/comparison-of-local-part-in...

It's complicated but thankfully you don't have to reinvent the wheel:

https://github.com/JoshData/python-email-validator (my project)

The README covers a lot of ground: internationalized domain names, internationalized local parts, SMTPUTF8, Unicode normalization, not performing SMTP checks, not permitting obsolete email syntax, and missing UCS-4 support in Python 2.7.

Previous discussion: https://news.ycombinator.com/item?id=5763327

I recently had a requirement to transform email addresses within free text into clickable mailto: links. That needs a regex.

/[^ ]+@[^ ]+/ is OK except for trailing punctuation, double @'s, and it definitely doesn't work with that quoted example. The first Rails one in this post /\A[^@]+@([^@\.]+\.)+[^@\.]+\z/ is at least better than what I came up with - I'll take a battle-tested regex if it's on offer.

I dunno, I think something very broad like /.+@.+\..+/ is probably good enough to catch like 99% of input problems. Gimme a string, an at-symbol, a string, a period, then another string. I don't think you can actually have an email that won't match this pattern?

But instead of showing an error you can just kinda say, hey are you sure you want that? and let them do it anyway. this is more of a validation suggestion.

I tell everyone the same thing about access control. Don't check access.

Also, never check file existence.

These things just take up time, introduce race conditions, and can't be trusted anyway.

That said, there are reasons to want to check some things with UI-level validation because calls to a slow back end are slow. Thus the name. I get that.

So if you're doing UI validation, don't get it right. Just get it mostly right. And do it fast. Cheat!

> I tell everyone the same thing about access control. Don't check access.

This caught my eye and I’m dying to know more - could you elaborate or point me to a good resource on this? My team has been dealing with some issues related to this recently.

It may be in reference to TOCTOU. [0] If you check that you can access a resource before you access that resource, you have implemented a race condition where you could potentially lose access to the resource in between the check and access attempt. It's probably not an issue if you have proper error handling, but it seems common to check that access is allowed then assume the resource will still be accessible later, without handling errors for when it's not.

[0] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use

Thank you so much for sharing this!

I gave a very fun talk on the topic in FOSDEM (VOLUME WARNING!):

https://www.youtube.com/watch?v=xxX81WmXjPg

It's more a joke than edifying, but it was very fun for me (and, I think, the audience), and illustrates the difficulty of email validation well.

I've always loved the "Email Hates The Living" talk[0] and am sad it's not available in higher quality. This is a great alternative.

[0] https://www.youtube.com/watch?v=4s9IjkMAmns

You can validate the field with whatever you want. It's going to be your data that you have to deal with later. Don't want users to use comments in emails? Don't validate them.

There is not reason whatsoever to validate to a standard just because it's a standard. Validate to what you will support.

Someone could submit several fake email email addresses and negatively impact your domain name email reputation.

I have a domain that is all digits. It passes validations in 99% of web forms, but email silently fails to deliver in about 10% of cases. So there is a great disconnect between web form validations and actual mail sender validations.

The worst is the behavior from, for example, CVS, where they accept a .email TLD in one place and reject it in another. At least have one set of rules. PayPal has the same problem.

Past comments: https://news.ycombinator.com/item?id=4486108

Half the computers in the world don't realize that + is a valid character in an email address, because programmers keep rolling their own email validation.

This is horrible advice. If you don't check input for correctness at all, an attacker could inject all kinds of nastyness into am underlying system, which may expose bugs.

For example, control characters, line breaks, shell escape characters, SQL injections, or simply uploading an ISO image into the E-mail field.

There is the RFC, and there is what we would nowadays consider a sane E-mail address. Nobody has addresses with spaces, nor does anyone have an address with an IP literal in it. Why? Because no other system will accept it. Think bank, etc.

TL;DR at the very least you need to validate field length, control characters, quote signs, and backslashes. Those have no business being in am e-mail address.

Ah, an old classic. Here[1] for example is a simple RFC 822 compliant email address recognizing regex:

    (?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
    )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
    \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
    ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
    \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
    31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
    ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
    (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
    (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
    |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
    ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
    r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
     \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
    ?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
    )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
     \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
    )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
    )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
    *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
    |\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
    \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
    \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
    ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
    ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
    ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
    :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
    :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
    :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
    [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
    \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
    \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
    @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
    (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
    )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
    ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
    :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
    \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
    \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
    ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
    :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
    ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
    .\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
    ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
    [\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
    r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
    \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
    |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
    00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
    .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
    ;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
    :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
    (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
    \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
    ^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
    ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
    ?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
    ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
    ?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
    \["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
    ])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
    ])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
    :\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
    \Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
    [^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
    ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
    ?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
    ()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
    ?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
    @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
     \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
    ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
    )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
    ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
    (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
    \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
    \r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
    "()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
    *))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
    +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
    .(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
    |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
    ?:\r\n)?[ \t])*))*)?;\s*)

Furthermore: "The regular expression does not cope with comments in email addresses. The RFC allows comments to be arbitrarily nested." Thus, clearly RFC 822 addresses cannot be described by any regular language. Ooof. I've been internettin' for a few years now and I had no idea that the email address format specifies comments.

[1] http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html

LGTM!

And then there are the validations that do not accept emails longer than x number of characters.

(Personal experience, yes.)

all these years later, and I still encounter systems that refuse to accept anything but a com/net/org/gov/edu email address. I have one ending in .fyi and .life and it's a no-go with a few places. Toyota, Paramount, and Experian come to mind.

My private mail is just _@mydomain. Recently some gov website didn't want that as an input...

I have an email that has “spam” in the name and I remember some form long ago disallowing its use. I assume they denied it thinking it was fake.

Why are rfc compliant regexes not a part of the stdlib of most languages?

you could check some common PGP keyservers for a key corresponding to the email address. if it isn't uploaded, treat the email as unverified and untrusted.

daydreams about strong cryptography

please don't do this, i like website using those shitty regex, allows me to use shit address instead of temporary ones..

I won't!

https://emailregex.com/

I recently encountered this thing, which I'd never seen before: https://html.spec.whatwg.org/multipage/input.html#valid-e-ma...

The original standard for email addresses seems to be so bad that it's just being scrapped and ignored. I think I'm OK with this.

  ```
  //pseudo Go
  import (
    "strings"
    "internal/inputs"
  )
  
  func emailValid(input inputs.ProfileInput) bool {
    if len(input.Email < 3) {
      return false
    }
    return strings.Contains(input.Email, "@")
  }
  ```

An email should be at least 3 chars long and contain a @ sign to be valid.

a@a can be a valid email address if your hostname is a and your mta accepts the email address. A user a may or may not exist (virtual).

And as the author wrote 10 years ago, if the mail doesn't arrive, no validation can help if the email address doesn't exist. But len>=3 and @ sign presence is enough of a sanity check.

I like the simplicity, but @@@ isn’t a valid email address (and .@. isn’t too, same as @…---…, and soon enough we’ll quickly regress back to the original problem of having too long of a regex)

I'm happy for my service to quickly and correctly validate 99.999% of emails and I don't really care if your oddball edge case emoji Sanskrit 6-level-deep domain fails. Just do normal stuff.

I once suddenly couldn't log in to a paid bike renting service app because it wouldn't accept my (valid at sign-up) email on login as it had a '+' symbol. There was basically no way to contact the developers and it was impossible to get the support people to understand what my problem was so I literally never used the service again. Don't try to parse email with regex, it's just not worth it.

This occasionally happens to me with a "category.site@depingus.mydomain.com" email address. I also respond by never using that site again.

It has to be a very niche service for you to not have any users with a name that doesn't fit in the pointless constraints of US-ASCII.

Reply on news.ycombinator.com