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

141–150 of 228 posts

Re: Stop Validating Email Addresses with Regex (2012)

#141

Post by discardedrefuse »

phreack wrote: post #14
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.

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.

Re: Stop Validating Email Addresses with Regex (2012)

#142

Post by jeroenhd »

tzs wrote: post #119
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 mea…

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.

Re: Stop Validating Email Addresses with Regex (2012)

#144

Post by northisup »

charles_f wrote: post #124

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…

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

Re: Stop Validating Email Addresses with Regex (2012)

#145

Post by remram »

VincentEvans wrote: post #108
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 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, f…

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

Re: Stop Validating Email Addresses with Regex (2012)

#146

Post by jancsika »

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…

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

Re: Stop Validating Email Addresses with Regex (2012)

#147

Post by Tagbert »

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.

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.

Re: Stop Validating Email Addresses with Regex (2012)

#148

Post by jeroenhd »

wolrah wrote: post #58
gleenn wrote: post #7

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

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.

Re: Stop Validating Email Addresses with Regex (2012)

#149

Post by wombatpm »

northisup wrote: post #144
charles_f wrote: post #124

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…

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

Re: Stop Validating Email Addresses with Regex (2012)

#150

Post by thrwyoilarticle »

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…

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.

Post reply on HN