Live data from Hacker News

Stop Validating Email Addresses with Regex (2012)

davidcel.is

181–190 of 228 posts

Re: Stop Validating Email Addresses with Regex (2012)

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

One important aspect of this that I often see people forgetting is that this check is designed for working with ASCII, but the domain name at least can be non-ASCII. User interfaces should remember to support IDN in domain labels and convert it to punycode before validating, and if you store A-labels (which you probably do) then convert it back to IDN form when presenting it to users.

(Alas, still doesn’t support non-ASCII in the local part, which isn’t supported everywhere but is, I believe, fairly widely supported now. See https://github.com/whatwg/html/issues/4562 plus https://en.wikipedia.org/wiki/Email_address_internationaliza... for a little more background on what it is.)

Re: Stop Validating Email Addresses with Regex (2012)

#182

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…

I'm pretty sure email addresses are allowed to have multiple @'s. I believe everything after the first is (supposed to be) considered part of the domain.

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.

Re: Stop Validating Email Addresses with Regex (2012)

#183

I think an initial test with regex is valid. But you should do a proper email validation link. That being said, you need to be very careful with what regex validation you are doing. I still use an apple "@me.com" email. Somewhere there is a commonly used library (or commonly used regex copied from stack overflow) that seems to fail because my domain is short. I have had a number of times that I have been unable to ge…

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…

I have the same problem on about 10% of sites.

I had a big ecommerce site go into their DB the other day and update from my temp email to my real. Now my profile is fucked because it validates the email address on the page load.

Re: Stop Validating Email Addresses with Regex (2012)

#184
post #179

I wrote an email validating regex at one point. It checked that there was exactly one @ sign in the address, which was neither the first nor last character. Seemed like a pretty good compromise to me.

Still incorrect. Valid email addresses can contain multiple '@'s as long as all but one are quoted.

Yes but why would you do this other than to be extremely smug when forms fail for you?

Re: Stop Validating Email Addresses with Regex (2012)

#185

  ```
  //pseudo Go
  import (
    "strings"
    "internal/inputs"
  )
  
  func emailValid(input inputs.ProfileInput) bool {
    if len(input.Email 
An email should be at least 3 chars long and contain a @ sign to be valid.

a@a can be a valid email address if your hostname is a and your mta accepts the email address. A user a may or may not exist (virtual).

And as the author wrote 10 years ago, if the mail doesn't arrive, no validation can help if the email address doesn't exist. But len>=3 and @ sign presence is enough of a sanity check.

Re: Stop Validating Email Addresses with Regex (2012)

#186
I dunno, I think something very broad like /.+@.+\..+/ is probably good enough to catch like 99% of input problems. Gimme a string, an at-symbol, a string, a period, then another string. I don't think you can actually have an email that won't match this pattern?

But instead of showing an error you can just kinda say, hey are you sure you want that? and let them do it anyway. this is more of a validation suggestion.

Re: Stop Validating Email Addresses with Regex (2012)

#187
The last time I implemented something like this we used a little library to check for typos on common domains and gave users a chance to correct on the front end before submitting. It significantly cut down the frequency of bad email addresses.

All of the other stuff is important too, but the most common issue is going to be someone tying "gnail" instead of "gmail", not having an obscure domain.

On a related note, I have mylastname@gmail.com and I receive emails from other people with my last name several times every week. I am almost certain they mean to type [firstinitial]mylastname@gmail.com but miss that first character. That's my working theory anyway. I've had to intervene multiple times when getting sent important medical emails for a different person with my same last name.

Re: Stop Validating Email Addresses with Regex (2012)

#188
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

Related: I used to use me@.com but gave up because Gmail uses "Me" as the name when displaying a user's own email address and it was confusing people enormously because a thread would look like:

>>>Me wrote: >>Me wrote: >Me wrote: Me wrote:

Re: Stop Validating Email Addresses with Regex (2012)

#189

Earlier quoted context omitted.

That can be a valid complaint as long as it's not about the logic or rules themselves, but how they're expressed in the code. Code that your team members can't work on is a liability.

Agreed. I see complexity as kind of a mass , and our job is in part to reduce it as far as possible. Like mass, you can shuffle complexity around, or add more, or discover unexpected ways to reduce it, but there is no way to reduce it below the problem's lower bound. Sometimes, the solution is as simple as it's going to get, and it's still complicated. State management is a good example. I'm more referring to that si…

> Sometimes, the solution is as simple as it's going to get, and it's still complicated. State management is a good example. I'm more referring to that situation.

That's fair. There is definitely irreducible, or essential complexity that we have to deal with.

Re: Stop Validating Email Addresses with Regex (2012)

#190
post #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.

Quoted strings are actually used in the real world, though they're certainly not common.

Shitty front ends are definitely putting an end to that, though.

Post reply on HN