Live data from Hacker News

Stop Validating Email Addresses with Regex (2012)

davidcel.is

161–170 of 228 posts

Re: Stop Validating Email Addresses with Regex (2012)

#161
post #160

Earlier quoted context omitted.

> If either string has a space or other invalid character, it's invalid Nope, could have a quoted string which can contain whitespace. addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part qtext = %d33 / ; Printable US-ASCII %d35-91 / ; characters not including %d93-126 / ; "\" or the quote character obs-qtext qcontent = qtext / quoted-pair quoted-string = [CFWS] DQUOTE *([FWS] qcon…

Sure. Fine. Skip that part then. The larger point I was trying to make still stands.

Sorry, I added more issues as I copied the corresponding snippets from the RFC.

Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start.

Re: Stop Validating Email Addresses with Regex (2012)

#162
post #153

Earlier quoted context omitted.

Similar experience for me. Many online forms fail to accept any email extension that isn't ".com", ".net", ".edu" or ".org". I'm surprised, because developers should know better that there are many more extensions beyond these four. Here is a full list of domain extensions available: https://www.name.com/domains . Let's just say one of these is registered and used as my email. I have found two ways of getting around…

Here is the actual, official, list of TLDs: https://www.iana.org/domains/root/db

Thank you. I figured there was a more official list out there.

Re: Stop Validating Email Addresses with Regex (2012)

#163

Can't upvote this enough. 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…

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

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Re: Stop Validating Email Addresses with Regex (2012)

#164
post #160

Earlier quoted context omitted.

Sure. Fine. Skip that part then. The larger point I was trying to make still stands.

Sorry, I added more issues as I copied the corresponding snippets from the RFC. Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start.

> Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start.

This is actually the whole point of what I wrote. Making the maintenance of the code low-effort, and having it be more permissive (i.e. less valid) and relying for the corner cases to be taken care of via email bounce.

See: explainer on "Now you have 2 problems"

https://arstechnica.com/information-technology/2014/05/what-...

If you read this whole comment thread you can see where this leads: increasingly complex regex in order to handle all the corner cases. Forget the corner cases, just make it "good enough" and relegate those corner cases to email bounce.

Now - I don't have a case study to prove that this way of going about it is more valid than the strict regex validation you're suggesting. But I wanted to represent it as a middle ground between "just rely on email bounce" and "write a big long regex".

Re: Stop Validating Email Addresses with Regex (2012)

#165
post #164

Earlier quoted context omitted.

Sorry, I added more issues as I copied the corresponding snippets from the RFC. Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start.

> Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start. This is actually the whole point of what I wrote. Making the maintenance of the code low-effort, and having it be more permissive (i.e. less valid) and relying for the corner cases to be taken care of via email bounce. See: explainer on "Now you have 2 p…

I like the first comment on that article:

  Some people, when trying to explain something, think "I know, I'll use a Jamie Zawinski quote." Now they have two things to explain.

Re: Stop Validating Email Addresses with Regex (2012)

#166
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…

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.

Re: Stop Validating Email Addresses with Regex (2012)

#168

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

A small subset of typos. bob@mail.com and bob@mial.com will pass the same validation rules.

Re: Stop Validating Email Addresses with Regex (2012)

#169
Regular expressions are validators of user input. Verification of user inputs are very important because they provide error messages, if you just send an email and it fails it can be for many reasons:

1. The user made a mistake when typing the email.

2. Some internal server failed to send the email.

Without an error, the user will never know what went wrong.

Re: Stop Validating Email Addresses with Regex (2012)

#170
post #113

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…

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