Live data from Hacker News

Stop Validating Email Addresses with Regex (2012)

davidcel.is

191–200 of 228 posts

Re: Stop Validating Email Addresses with Regex (2012)

#191

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.

Not all uppercase characters have just one lowercase representation, and not all lowercase characters have an uppercase character. If you try to make the addresses case insensitive, you're bound to run into unnecessary complexities at some point.

Email addresses aren't case insensitive in nature, but many commercial mail services (and misguided developers) assume they are.

Re: Stop Validating Email Addresses with Regex (2012)

#192
I think normalising emails is equally important these days, esp if you are offering any sort of free trial on your website (that incurs a cost to the seller) as it has become quite common for freeloaders to create dozens of accounts using the dots and plus signs just to abuse the free services.

Re: Stop Validating Email Addresses with Regex (2012)

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

And we lost the 0.00001% of the market that has such an email address.

Re: Stop Validating Email Addresses with Regex (2012)

#194

Earlier quoted context omitted.

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

The parent's regular expression covers the most egregious typos without making any assumptions about domain names or tlds. If you wanted to help out with common typos you could add additional logic to specifically check for "*@gmial.com" or other permutations of the common domains. If you wanted to get really fancy, you could even run it by an edit distance function against the common domains and warn if they're clos…

It misses the very common mistake of typing a comma instead of a dot.

Otherwise, yeah, most people would be better served by a library that detects domain typos like https://github.com/mailcheck/mailcheck than spending time on regexes.

Re: Stop Validating Email Addresses with Regex (2012)

#195

Validate emails in a manner that is representative of the typical use of your service. If it’s a specialist email processing tool, then you should probably follow an RFC. If it’s a dating app, you can probably just use a regex that covers common cases to help users avoid typos. I think the decision is similar to the one picking how modern are the browsers you are going to support. It’s a trade-off. That’s my take on…

I'm not sure there are even many SMTP servers that fully follow the RFC. Embedded comments in an email address is a weird feature.

Re: Stop Validating Email Addresses with Regex (2012)

#196
post #166

Earlier quoted context omitted.

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.

I'd say that's for the better.

Re: Stop Validating Email Addresses with Regex (2012)

#197
post #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 h…

I like the simplicity, but @@@ isn’t a valid email address (and .@. isn’t too, same as @…---…, and soon enough we’ll quickly regress back to the original problem of having too long of a regex)

Re: Stop Validating Email Addresses with Regex (2012)

#198
2012? And it seems so little has changed. Several times per month I am told by websites that my supplied email isn't valid even though it can receive email. All because it is using one of the "new" top level domains ".email" and has been for 6+ years now.

The breakdown of websites this happens most on are large corporate websites or very small online shops using some no-name shopping cart software.

Re: Stop Validating Email Addresses with Regex (2012)

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

Says who? I don't consider that address valid.

Re: Stop Validating Email Addresses with Regex (2012)

#200

Earlier quoted context omitted.

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.

> in practice their only use these days is attacks where you confuse a badly-written server

Or, you know, if you actually want to use an at sign in the manner allowed by the RFCs. That's the point of standards: if something is allowed, then … it is allowed.

Refusing to accept behaviour permitted by the standard is just broken.

Post reply on HN