Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Validating Email Addresses with Regex (2012)

davidcel.is

Post reply on HN
Print view View original

201–210 of 228 posts

Re: Stop Validating Email Addresses with Regex (2012)

#201

Post by harshreality »

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.

Re: Stop Validating Email Addresses with Regex (2012)

#202

Post by hathawsh »

qwerty456127 wrote: post #111
hathawsh wrote: post #41

Earlier quoted context omitted.

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…

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

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

Re: Stop Validating Email Addresses with Regex (2012)

#204

Post by throwaway787544 »

jve wrote: post #118
throwaway787544 wrote: post #114

Earlier quoted context omitted.

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

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.

Re: Stop Validating Email Addresses with Regex (2012)

#205

Post by chrismorgan »

eadmund wrote: post #200
chrismorgan wrote: post #182

Earlier quoted context omitted.

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

Re: Stop Validating Email Addresses with Regex (2012)

#206

Post by Avamander »

jeroenhd wrote: post #139
kingcharles wrote: post #64

Earlier quoted context omitted.

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…

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.

Re: Stop Validating Email Addresses with Regex (2012)

#207

Post by Avamander »

Beltalowda wrote: post #9

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 art…

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.

Re: Stop Validating Email Addresses with Regex (2012)

#208

Post by Avamander »

derekjbernard wrote: post #83

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.

Re: Stop Validating Email Addresses with Regex (2012)

#209

Post by Avamander »

arthurcolle wrote: post #23
pkrumins wrote: post #16

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.

Re: Stop Validating Email Addresses with Regex (2012)

#210

Post by Avamander »

mdoms wrote: post #6

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.

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.
Post reply on HN