Email address validation: please stop

Hope is all you have, if email is the black box wilderness you describe. You rely on hope regardless of whether or not your email address contains "super-special characters".

My whole point is that there is a standard for an email address, outlined in a freely-available document. If an application claims to handle email, that claim implies conformance to that standard. Any deviation should be documented.

Your claim appears to be that there is some other definition of a "legit" email address, that you can absolutely 100% guarantee will be handled by absolutely every single email-handling application ever (without relying on hope).

Please answer these questions -

1) What, exactly, is the format of such a "legit" email address, according to your definition?

2) Where does this definition come from?

The activation email isn't a panacea for users fumble fingering (or misremembering, or not knowing) their email address. Users who don't receive it will either a) ignore it if you let them use the application anyway or b) frequently bounce hard if they don't get it, because they assume naturally that your Googles are broken.

The single most compelling reason to send people activation emails is -- I kid you not -- to remind them that they signed up for your website and how to get back to your website. A secondary consideration is not proving that they got their inbox right but proving that they didn't get someone else's inbox wrong.

I ran into this with a flight reservation system. I lost hundreds of dollars and missed my flight when the front end accepted my email address but the back end didn't send me a confirmation.

A plausible explanation given to me was that the web application worked just fine, but it sent the data to some COBOL-ish back end written long before the advent of web bookings, and the integration code mangled my email address when it stuffed it into some data field that was never intended to hold an email address.

This is why any real-world system needs end-to-end integration testing and not just unit testing :-)

Your view of this whole subject seems to be completely upside down.

There's no such thing as a 100% guarantee when it comes to email (Interwebs 101) but it should be completely obvious to any sane person that you are getting much closer to those 100% if you don't use any "super-special characters" in your e-mail address as opposed to people "asking for it" by using an address like {^|~!}@gmail.com - which will obviously get you into some kind of trouble, sooner or later, whether it's Facebook's validation rejecting it or mail applications which can't handle it properly.

So of course, while there can't be 100%, from the perspective of an application that deals with e-mails, you'd want to get as close as possible. And like I said in an earlier comment, I wouldn't expect problems with characters such as - _ . but yeah, who knows?

And actually, there's no way anyone could ever have that obscure example address used above, as hey surprise, GMail won't allow you to register it (same for Hotmail). So, I am not sure what this means now:

GMail only allows alphanumeric characters and dots in mail addresses because...

a) ...their coders don't know the RFC and hardly anything about that whole e-mail thing in general, so they provided us with a heavily flawed product, according to your definition.

b) ...their coders have already been doing this whole development and e-mail thing for a week or two and it was obvious to them that "super-special characters" could lead (and have previously led) to trouble, so they're saving less 'techy' people from registering addresses that are basically "asking for it".

Ever since the first comment I left here, my whole point is that everyone who has built applications sending a lot of e-mails just knows that it's insane to assume that everybody else "does it right" and that combinations of special characters, escaping and UTF-8 often result in 'lots of fun'... not. That's far from being fully RFC-compliant but that's how it is, out there in the wild.

One last example: according to Wikipedia, Hotmail "refuses to send mail to any address containing any of the following standards-permissible characters: ! # $ % * / ? ^ ` { | } ~". (And being aware of this, you'd be "asking for it".)

Shouldn't the spammers have figured out the "+" feature by now? Just remove it and the suffix to get a valid address, for gmail or any other provider that uses the syntax.

return Regex.replace(email, "([^\+])°[^@]°(@.°)$", "$1$2")

° should be * but HN eats it as markup.