Hacker News Reader

Comment by strictnein | Hacker News Reader

Many hours spent here, trying to create the ultimate email regex, while telling my PMs and managers that there was no such thing.

View on HN

Been there, done that. There's only one way to check email addresses: /.+@.+/

Anything else is going to give you a false negative sooner or later. Yeah, you can spend hours framing a complicated expression that carefully tests for exactly what the current bucket of RFCs specify, but you're guaranteed to run into an MTA somewhere that disagrees with you, and you can argue until the cows come home that you're right and they're wrong, but it's still you that's going to have to change to accommodate them in the end.

I would think you'd use: /.+@.+\..+/

nope. root@localhost is a valid mail address.

How often are you validating email addresses for localhost!? Those are pretty much never a valid email for >>>99% of applications

Right, so if you're not going to accept the full RFC then where do you draw the line? Your arbitrary line will assuredly be different from someone else's.

That's the whole point of the original post: don't bother thinking about it, let the mta do that for you. The "@" is a courtesy to make sure people didn't mistakenly put their name in. Don't validate, just do a sanity check.

And people are just as likely to type an valid but incorrect email address as a invalid email address.

That's why you also implement an email verification method if you actually care that it's a correct email as well as valid.

Historically there have been many valid RFC 822 addresses without an @ in them. I don't know how many can still be delivered to though.

In the back of the Camel book there is an email matching regex. It takes the entire page. It probably doesn't handle some Unicode edge cases properly.

Validating emails with regexes is one of those things that seems like it should be fairly straightforward, but thanks to the language in the RFC it is actually a nightmare of rabbit holes filled with landmines.

That would be the one shown here:

http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html

I don't know about unicode, but I do note it says it doesn't handle comments (because, apparently, they can be nested - and perl's REs lack recursion).

> Implementing validation with regular expressions somewhat pushes the limits of what it is sensible to do with regular expressions

(rest of the page is filled with line noise)

LOL

Perl has supported recursion in regex since around v5.10. The giant regex is not from the Camel book, but from O'Reilly's, Mastering Regular Expressions which does give the example in Perl, but was printed before v5.10 of Perl was released. (3rd ed. of Mastering Expressions was released in 2006; Perl v5.10 was released in 2006.). I believe the regex was published in the very first edition.

Ah yes, sorry, it would have been more correct to say "perl's REs lacked recursion at the time ". I use PCRE pretty frequently, so knew that it's supported recursion for some time; but it's been a while since I've done anything non-trivial with perl itself, so couldn't remember if it too had that functionality or I was just getting their feature-sets confused. Evidently I guessed wrong - thanks for the correction.

RFC 822 is the Internet's cancer.

Really. Email addresses should have never been allowed to have comments.

Since every new RFC maintains compatibility with this one, we'll probably be stuck with these poor choices for decades.

Email addresses allow comments? Who the heck thought that was a smart idea!?

I guess this is what you're referring to: James Doe <jdoe@a.com>

The email - which is inside the <> - should be parsed correctly, while the rest should be treated as a "comment" [1].

[1]: https://www.cs.tut.fi/~jkorpela/rfc/822addr.html

No No.

Stuff like:

* comments are allowed with parentheses at either end of the local-part; e.g. john.smith(comment)@example.com and (comment)john.smith@example.com are both equivalent to john.smith@example.com. [1]

* Also have a look at quotes

[1]https://en.wikipedia.org/wiki/Email_address#Local-part

what.

Guess I'm in today 10000 who learned something today.

I can't understand this sentence.

At first I thought you were a bot. Then that your English was not very good.

Looking at your history clearly both are false.

What did you mean?

I think he meant: "I guess I'm among the 10000 who learned something today".

They're referring to this: https://xkcd.com/1053/

Good catch, forgot about that one!

Now it makes sense.

Thank you!

These are all valid email addresses!

    * "Abc\@def"@example.com

    * "Fred Bloggs"@example.com

    * "Joe\\Blow"@example.com

    * "Abc@def"@example.com

    * customer/department=shipping@example.com

    * $A12345@example.com

    * !def!xyz%abc@example.com

    * _somename@example.com

http://haacked.com/archive/2007/08/21/i-knew-how-to-validate...

RFC 822 is what happens when you try to standardize a system in such a way that it is backwards compatible with every home grown system on the planet.

Have further RFCs not deprecated most of the braindamage from 822? If not, why? Are there really people who are still trying to use such horrible abominations for their email address?

And the irony is that regular expressions, by definition, can't recurse. Nobody's gonna rename them to turing expressions, though.

The issue is not regexing, it's lack of real standard in email format :)

    ^(?("")(""[^""]+?""@)|(([0-9a-z]((\.(?!\.))|[-!#\$%&'\*\+/=\?\^`\{\}\|~\w])*)(?<=[0-9a-z])@))(?(\[)(\[(\d{1,3}\.){3}\d{1,3}\])|(([0-9a-z][-\w]*[0-9a-z]*\.)+[a-z0-9]{2,17}))$

This and other email validation here: https://github.com/neosmart/web/blob/master/Web%20Toolkit/Em...

Is that chinese character compatible? (half-serious)

What I don't understand is, don't programs like thunderbird or mutt have a module or function for email sanity check, and why hasn't that been ported as a module for every language imaginable?

Being the maintainer of that would be the worst programming job possible.

I'm going to have to go ahead and agree with a comment in the javax internet address code here, if you insist on checking against the rfc, you should really just give up and use a lexer.

This one covers like 99.9% of the cases: [\w]\S+@\S+[a-z]+

The pedant in me wants to point out that the TLD can be uppercase, as the domain part is case-insensitive.

In any case, it probably won't be too long before we get emoji TLDs, or UTF8 flags to replace the country-code :-D

Reply on news.ycombinator.com