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.
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.
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.
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.
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.
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).
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 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).
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.
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.
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.
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.
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.
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.
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 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.
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.
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
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.
"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."
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 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:
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)
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.
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.
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.
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]
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.)
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:
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.
> 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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:
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.
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.
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.
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
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.
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.
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.
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.
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.
227 comments
[ 3.0 ms ] story [ 239 ms ] threadI won’t ask people to type the email twice, that’s just annoying.
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.
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...
All solved by a password manager.
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).
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.
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.
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.
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.
(which as far as I understand is also to protect the emailing service from getting blocked itself)
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.
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.
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.
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 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.
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...
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 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 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.
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.
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.
https://mail.gnome.org/archives/evolution-list/2002-January/...
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:
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.
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.
That's not entirely true, it depends on how your mailing infrastructure is set up.
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.
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.
Email addresses aren't case insensitive in nature, but many commercial mail services (and misguided developers) assume they are.
1. https://en.wikipedia.org/wiki/Email_address#Internationaliza...
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.
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.)
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.
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
>>>Me wrote: >>Me wrote: >Me wrote: Me wrote:
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.
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.
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.
Shitty front ends are definitely putting an end to that, though.
(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 used an-emoji.my.domain for a while until chrome changed it back to punycode
/[^ ]+@[^ ]+/ 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.
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!
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.
[0] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
daydreams about strong cryptography
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?
As others pointed out, for a sanity-check something like /.+@.+/ should be good enough.
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.
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).
You can see the email address on the front page if I paste the punycode web address on here:
https://xn--bp8hgh.to/
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!
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.
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.
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.
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).
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.
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.
I am :)
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
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.
https://emailregex.com/
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.
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
When you're dealing with signups for a service, there's absolutely no reason to refuse a working email address.
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.