Live data from Hacker News

Stop Validating Email Addresses With Your Complex Regex

davidcel.is

81–90 of 211 posts

Re: Stop Validating Email Addresses With Your Complex Regex

#81
post #30

Earlier quoted context omitted.

I understand the argument re validating email addresses passively (regex, no regex, etc.) vs actively (send an email by SMTP). What I don't understand with this ever-repeating discussion is why the complexity has to be visible. e.g. > > Yeesh. Is something that complex really necessary? Many functions are complex - we put those in libraries, pushing them under the hood, and move on. What is so special about parsing e…

> What is so special about parsing email addresses that makes everyone invent their own solution - regex or otherwise? A valid email address can contain almost anything; this makes validation via a standard parser mostly useless. As such, devlopers reach for stricter parsers out of a combination of a not comprehending the standards, feeling vague discomfort about letting 'just anything' past data validation, and misp…

> misplaced concern for users that they believe can't type their own e-mail address

How is this misplaced? People screw up even the most basic of computer tasks all the time.

Re: Stop Validating Email Addresses With Your Complex Regex

#82
It's an interesting intellectual exercise to build THE email validation regex, but it's shortsighted to inflict your experiment on the public.

While I definitely enjoyed how Friedl's book (http://regex.info/book.html) builds over several chapters to an ever more complex solution, maybe a page long, my takeaway was: don't bother. A friendly UI will help users avoid an obvious mistake, but as other posters have pointed out, the only real validation is, does an email get there?

Re: Stop Validating Email Addresses With Your Complex Regex

#83

This has been an issue since the day I started programming for the web, back somewhere in '95. It has regularly come up on HN, and pretty much any programming related forum I've used since the mid-90's. As an industry at the heart of the information society you have to wonder what the hell we are doing wrong if we cannot stop this constant regression into well known bad practices.

I think it's mostly just bikeshedding. This is a problem that is both largely unimportant but also common enough that many have encountered it (and thus have an opinion).

Re: Stop Validating Email Addresses With Your Complex Regex

#85

Amen! Anyone else here use myemail+token@gmail.com when they have to register with their email to find out who is selling them out and to make spam filters easier? It still amazes me that 70% of the places I attempt using foo+bar@gmail.com call it invalid. And that does not even begin to touch the myriad valid permutations that are "invalid" out there.

Maybe they're on to you and only pretend that they think it's invalid so you'll give them a slightly-less-throwaway address ;)

Re: Stop Validating Email Addresses With Your Complex Regex

#88
post #25

Earlier quoted context omitted.

I thought new TLD being worked on didn't need to have dots in them. Why not just check for x@x?

That's exactly what you should do. ^(.+)@(.+)$ max length is 254 according to the RFC I believe, so you can check for that too.

IIRC, last I checked max length was 320.

Re: Stop Validating Email Addresses With Your Complex Regex

#89

Yeah, and then you wind up sending mail to "joe@hotmailcom" or "liz@gmailc.om", and your users don't get your messages and are sad. Don't validate the local part, do validate the domain.

Especially since this is extremely easy to do, it’s just three DNS queries away (plus one in case of CNAMEs).

Re: Stop Validating Email Addresses With Your Complex Regex

#90
I don't think this is good advice.

From a previous startup we saw a ton of signups like, "john@gmail" and the like. Obviously this person will not get a validation email -- and in all likelihood will not be able to log in to his account when he returns. It's best to catch him when he's entering the information.

Post reply on HN