Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 153 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

TL;DR: Stack Overflow's (and Stack Exchange's) client-side and server-side code rejects valid e-mail addresses, this should be fixed: preferably by only making a basic check, e.g. ^[^@]+@[^.]+(\.[^.]+)+$ (as e-mail address validation with JS is an exercise in futility).

Stack Exchange is the network that tries to

Make the Internet a better place to get expert answers to your questions;

yet, for all the excellent Q&A we have on e-mail address validation, I was horrified when a user uncovered that this site itself uses a horrible, terrible, no good e-mail "verification" regex:

That thing looked eerily familiar. Indeed, it is the notorious regex from - which "matches all valid e-mail addresses". Or so the author claims - as he immediately adds that "I consider everything not matched by this to be invalid"; I see that logic as slightly circular, although he does have valid points for choosing that pattern in his specific situation (e.g. "meh, this is just a simple website, why bother with three nines?" and "there's no perfect regex anyway"). Alas, due to the Bathroom Wall Of Code effect, this regex found its way into various collections of "useful regexes" and thence to SO. Unfortunately, it seems that the various regex snippet libraries only disclose the first part of @Jan Goyvaerts' assertion ("matches all valid e-mail addresses"), without highlighting the tradeoffs and pitfalls of this snippet (which the author discusses in quite some depth on the aforementioned page).

Now, there's a lot of discussion and controversy on "the right way to validate e-mail addresses", and I think e.g. this question addresses the technical parts excellently; but on top of that, amongst my issues with this particular usage are:

  • a small site somewhere on the Net can get away with "I'll just reject your e-mail address because **** you, it's my site, now go away already"; that is an inappropriate approach for Stack Exchange.
  • the regex is outdated and inaccurate, what with the new(ish) IDNs and ancient outliers such as .travel and .museum.
  • and worst of all, it gives a bad, you could even say hypocritical, example: "do as we tell you, not as we do" - it is rather awkward to explain to people that no, this is a bad way to validate e-mails, on the same site which uses that code - see the comments under this question. Also, we're actively contributing to the Bathroom Wall of Code effect ("Can we make a search-and-replace on the entire Internet? ... Oh.").

Let me quote from Validate an E-Mail Address with PHP, the Right Way:

There is some danger that common usage and widespread sloppy coding will establish a de facto standard for e-mail addresses that is more restrictive than the recorded formal standard.

Do we want to be seen as perpetrators (propagandists even, as this is a network of sites for learning) of such "sloppy coding"? Such false negatives when validating addresses are the e-mail's equivalent of "all text is ISO-8859-1", IMNSHO.

So, I have three suggestions of variable insanity:

  • If there is a need (or an urge) to validate e-mails in JavaScript, since this check is only done once in a while, and then only when notification checkbox changes state (if I understand this correctly), the full ex-parrot regex would be useful
  • Should the SE team see this as overkill, I'd suggest making this a sanity check only - if it doesn't pass the (possibly too-strict) regex, ask user if xe really wishes to use that address, but don't prevent it.

Note that I wrote "If there's a need (or urge)": I don't think that it's possible to determine in JavaScript whether something is a valid e-mail address - it is possible to determine that something is not a valid e-mail address, but even well-formed e-mail addresses are not guaranteed to be valid: passes even the most restrictive tests, yet I doubt you would reach me there. JS e-mail address validation may have been easier in 1998 (without all those pesky newfangled 4+ letter TLDs and whatnot), but in 2011, it's an exercise in frustration and futility - in fact, I would even call it cargo cult programming: most people implement it because "must have JS e-mail validation, everyone else has it" - without any real benefits from what often becomes a misfeature.

  • So, by @Pekka's suggestion, and with the help of this question, I propose only checking for @ (and possibly a 2nd+ level domain name, but then it gets complicated again with IDNs and whatnot), and leaving the rest to the mail transfer agents - after all, those implement a parser for what is and what isn't an e-mail address (one would hope).

Edit: Like using MD5 for security, the problem isn't getting magically better by ignoring it. Quite the contrary, it's getting worse: Apart from the parallel IDN gTLD program, ICANN has recently (June 2011) announced golden-rule*, free-for-all gTLDs. If you think that excluding .travel is good policy because who cares, will it take something like .apple getting registered? This is - as of now - only a possibility, but it's another nail into the \.[a-z]{2,4}$'s coffin.

*The other golden rule obviously, as the vanity gTLDs will be quite expensive.

Edit 2: Oh dear. Apparently the regex lives in SO/SF/SU/SE's server side code as well - see the screenshot, complete with freehand circles. From this, I infer that there's another place in the code which assumes \.[a-z]{2,4}$ is correct. This is getting kind of silly.

share|improve this question
FWIW, the solution presented in that LinuxJournal article isn't actually up to spec -- the most up to date RFC is 5321, published in late 2008. I'm a fan of Dominic Sayers' work, as his library has a huge test suite for compliance. Unfortunately it's also PHP and not too useful for SO directly. (Edit: Whoa someone ported it to C#!) – Charles May 20 '11 at 18:29
@Charles: I'm not saying his is the One Regex To Rule Them All (and it's not a regex, on top of that); also the DNS checks that his proposed code does are unsuitable for a client-side check. I'm quoting his observation which sums up the state of affairs on what is and what is not perceived as a valid e-mail address. I'm proposing two solutions of varying insanity in the last paragraph. – Piskvor May 20 '11 at 18:32
Wow. The comments on that SO post are... let's just say "underwhelming"... but that is some good catch. – Pops May 20 '11 at 18:59
@Popular Demand: For such a reliable flamebait topic as "email validation regex", they are pretty tame (no Godwins as yet). – Piskvor May 20 '11 at 19:02
It was my fault, it is being used. Track XHR in Chrome Dev Tools and you'll see that it isn't sending an XHR for .museum addresses, whereas it is sending an XHR for .com etc. – pimvdb May 20 '11 at 19:41
Isn't E-Mail validation beyond *@* silly anyway? What is it good for in the first place? I've never really understood that, and can't see any arguments for it e.g. here - How far should one take e-mail address validation? – Pëkka May 20 '11 at 20:03
@Pekka: Now, I've noticed a tendency for this programme to get rather silly. Yours is IMNSHO a very reasonable suggestion, edited to add that. – Piskvor May 22 '11 at 9:24
For a site that went with OpenID as "the right way to do things" I'm surprised they implemented such a shortsighted email verification routine. – Adam Davis May 25 '11 at 13:25
@voter-to-close-as-OT: "Questions on Meta Stack Overflow are expected to generally relate to the Stack Overflow family of websites and/or community in some way" - how does "SE's Javascript logic is broken" not relate to Stack Overflow, given that it's broken on all sites of the S tack E xchange network? [mind boggles] – Piskvor May 26 '11 at 16:50
Surely an email validator could legitimately reject addresses at reserved domains, like ""? Although I emphatically, emphatically agree that this is one of the many, many cases that are not worth trying to filter out. – Jack V. Jun 6 '11 at 10:25
@Jack V.: Doing that in JS is kind of pointless - such whitelist would catch what, ten invalid domain names? Thirty? It will still let through‌​m,which is invalid (but good luck checking that in JavaScript ) – Piskvor Jun 6 '11 at 10:29
Oh, wonderful. [gets all Righteously Offended and goes to sulk in the corner: They won't fix my bu-u-u-ug now, aa-a-and it's my faaa-aavorite oooo-o-one!] ;o) – Piskvor Jun 30 '11 at 15:48
@Charles: Phalanger? – Mechanical snail May 27 '13 at 6:51
@Mechanicalsnail, what about it? The C# port of is_email is an independent work, not relying on Phalanger. is_email also doesn't seem to have been updated since my comment two years ago, which is a bit sad. – Charles May 27 '13 at 9:28
I wouldn't hesitate to use the full ex-parrot regex

I disagree. This is a regex that matches ALL valid email addresses but as you can see it's almost comical. Regexps are not the right tool for this.

I think there are two much better solutions:

  • Do it right with an old fashioned parser.
  • Don't do it at all. Don't go beyond checking if the email has a '@'. If someone wants to give you a fake email they will and there is nothing you can do about it. Just think of sites like mailinator.

I believe the second solution is better: no dev time wasted, less error prone (compare the difficulty of implementing a parser based on an RFC to checking if there is a '@'), less annoying for people using fake email addresses (which again they will if they want to), and doesn't try to solve a problem that can't be solved through validation checks.

share|improve this answer
Well, you are right that this is not a good use for regexes; IMNSHO, it's not a good use for anything - JS e-mail validation is mostly a cargo-cult exercise left over from the 1990s (when it may have served a useful purpose). Edited. – Piskvor May 21 '11 at 12:11
My eyes.. MY EYES ... – Tim Post May 23 '11 at 17:11
This regex validates RFC 5322 addresses. – tchrist May 25 '11 at 20:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .