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

111–120 of 228 posts

Re: Stop Validating Email Addresses with Regex (2012)

#111

Post by qwerty456127 »

hathawsh wrote: post #41
dchest wrote: post #17

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

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.

Re: Stop Validating Email Addresses with Regex (2012)

#113

Post by tough »

boplicity wrote: post #110
dchest wrote: post #17

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

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…

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

Re: Stop Validating Email Addresses with Regex (2012)

#114

Post by throwaway787544 »

boplicity wrote: post #110
dchest wrote: post #17

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

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…

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.

Re: Stop Validating Email Addresses with Regex (2012)

#115

Post by [deleted] »

kube-system wrote: post #100
remram wrote: post #96

Earlier quoted context omitted.

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

[deleted]

Re: Stop Validating Email Addresses with Regex (2012)

#116

Post by electroly »

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.

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.

Re: Stop Validating Email Addresses with Regex (2012)

#118

Post by jve »

throwaway787544 wrote: post #114
boplicity wrote: post #110

Earlier quoted context omitted.

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…

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.

Re: Stop Validating Email Addresses with Regex (2012)

#119

Post by tzs »

xurukefi wrote: post #55

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

Re: Stop Validating Email Addresses with Regex (2012)

#120

Post by bbatha »

Beltalowda wrote: post #97
turminal wrote: post #90

Earlier quoted context omitted.

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