
Stop validating email addresses with your complex regex - davidcelis
http://davidcelis.com/blog/2012/09/06/stop-validating-email-addresses-with-regex/
======
andrewvc
A couple years ago Evan Phoenix (of rubinius) and I collaborated (by which I
mean he wrote the grammar and I did almost nothing) on a _REAL_ RFC compliant
email address validator using a PEG for parsing:
<https://github.com/larb/email_address_validator>

I don't know that anyone uses it, or would even want to use it. It was a fun
project, but I certainly wouldn't use it in an app (unless it was an MTA or
MUA). What comprises a valid email address is way too broad.

I think there are reasonable regexes for email addresses FWIW. The RFC(s) are
stupid and broken, and you can hit 99.99999% of addrs and provide useful
errors back to the users with a regex.

~~~
garethadams
Sure, I mean `me@yahoo` is an RFC-compliant email address, it refers to a
local server 'yahoo'. However in your online app it's almost certainly an
error if this email address turns up in a registration form.

Don't test for an RFC-compliant address if you don't want to accept all RFC-
compliant addresses. Being able to send an email is a much better test because
it matches what you're going to use the email address for in your app.

~~~
jph
But your way, if the user makes a typo like "foo@@bar,com" then he will expect
to receive an email but wont. Better UX in my opinion is to do validation
before sending, both client-side and server-side (esp. good for REST JSON
APIs), then if these are all good send the welcome email.

~~~
drbawb
I wouldn't mind using a simple regex or validator to check the e-mail addr for
validity.

It wouldn't be RFC-compliant, but it would catch 99% of typos.

Instead of being an _error_ when the e-mail fails validation though, it would
say something like: "your e-mail does not appear valid; please double check
your entry. You will be sent an activation e-mail; click [Continue] if you're
sure the address is valid."

Basically if it fails the "99%" test, then if that fails, let the user decide
if their e-mail is in the 1% or not.

------
azylman
The biggest argument for not validating email addresses shouldn't be that
"it's hard". It should be that _email providers don't always follow RFC
guidelines_. At my old job, we had this really weird bug that, after a lot of
work, we tracked down to users who legitimately had greek letters in their
email addresses.

If there are legitimate emails that don't follow RFC, you should absolutely
allow users to enter non-RFC-compliant email addresses.

~~~
davidcelis
It's not hard, though. Anybody can go online and search for an email
validating regex, but as some have pointed out, many are too strict and don't
allow for, say, tagged email addresses (email+tag@example.com). There's email
validation, and there's overkill. That's what I was trying to get at.

~~~
azylman
The difficulty of writing regexes for email validation wasn't the main point -
the main point was that emails don't follow spec so any regex based on that is
inherently wrong. However, it seems like saying "most email validation regexes
are broken" is equivalent to saying "email validation regex is hard"

~~~
subsystem
They do most likely follow the standard, just a different standard than the
one you're thinking of. E.g. RFC6530.

------
imperialWicket
This technique is hinted about, and I don't claim it as my own creation. I
think the easiest (maybe not the best) route for both devs and users is:

[submit]

does email address have a '@' and a '.' after that?

yes -> send a validation email.

no -> Hey there, [email] seems like an odd address, are you sure?

    
    
           yes -> send a validation email.
    
           no -> restart
    

I think this does a reasonable job of staying out of everyone's way, and it
catches a large percentage of the actual typographical/user error email
entries.

[formatting edit]

~~~
justincormack
There used to be someone who had the email address john@dk (maybe it wasnt
john). Mx records on tlds are frowned upon but not technically invalid.

~~~
bigiain
imperialWicket's approach would still work fine in that case when john@dk
clicks the "Yes, that's really my email adress" button - and I suspect he'd be
pleasantly surprised to see it work, I'll bet he's got a very high expectation
of that address failing completely on most websites...

I have a cow-orker who's first name is "G" - he's very used to poorly-
validating websites claiming that his firstname is "wrong".

~~~
eru
Given by his parents?

~~~
bigiain
Yup.

I've got another friend/acquaintance who's got a fully legal (self chosen)
single name. No first/middle/last name, just a "mononym". He has the expected
hilarious outcomes with things like Google's "real name policy".

~~~
gadders
He? So it's not Cher?

~~~
bigiain
Nope. Can't even claim "acquaintance" whth Cher. Or Prince.

------
epochwolf
No, no, no, no. Normal people don’t always use the email field properly. The
might put the username in the email field and the email in the username. Just
check for an @. There is no email in the world outside your server that you
can sent to without an @.

~~~
davidcelis
I did that for a time (which I mention in the article), but it's still a
superfluous check on top of an activation email. If your users are typing the
wrong values into your registration form, perhaps you need better labeling or
placeholder text? Display an error that the activation email couldn't be sent.
But why add superfluous checks?

~~~
aaronpk
Knowing whether the email was sent is not always something you can do
synchronously.

A simple check for an "@" sign would go a long way to avoiding bounced mail
notifications from usernames being entered in email address fields.

~~~
davidcelis
Yes, agreed (and I mention this at the end of the article as well) and I still
use the /@/ regex often. But a good UI on the registration form can go a long
way in alleviating the "switching the email address and username fields"
problem.

~~~
pbhjpbhj
> _a good UI on the registration form can go a long way in alleviating_ //

But not all the way. And so a simple "you might have got this wrong" flag
would be helpful, no?

~~~
TeMPOraL
"You might have it wrong", yes. "You are wrong, we won't let you submit the
form" won't.

------
opminion
12345 could be a valid postcode in Germany or Spain, but in the UK it would
have to look like AB1 2CD, except when it doesn't (e.g. AB12 3CD). Arg!

I wish web forms had a "Tell us we are wrong" button next to validated boxes.

~~~
hcarvalhoalves

        I wish web forms had a "Tell us we are wrong" button next to validated boxes.
    

You know... that's a very good idea actually.

~~~
naww
I've been thinking about service that injects some lines of javascript for
client sites that gives them button "fix this". It would send warning email
after few messages about typos but it could also be used to fix these kind of
things. Not sure how JS could handle selection and button press
simultaneously. Maybe copy+paste part of page with fix. Maybe get some reward
for being grammar nazi. Maybe some paid service for auto checking if
corrections are accurate and auto-inject corrections to sites.

What the heck, how can I take MS Word online?

------
ch0wn
If your service tells me that myname+servicexyz@gmail.com is an invalid
address, you have to live without me. I can't count how many mails I sent to
websites incorrectly validating email fields. However, password validation is
mostly even worse. Just stop over-validating already!

~~~
erichocean
Agreed that password validation is the worst. (Github, I'm looking at you.)

Even worse than excessive validation is when they make you change your
password often, for no apparent reason.

On some sites that do both ( _ahem_ Apple), the only way I can login if I
haven't been there in awhile is the security questions or the password reset
mechanism.

~~~
ch0wn
Wow, I never noticed that Github enforces password rules, as well (Must
contain one lowercase letter, one number, and be at least 7 characters long.).
My passwords are usually HMAC-based, so they'll most likely validate.

------
codyrobbins
Using or not using a regex to validate email addresses misses the point. You
should simply be delegating this task to the library that you’re using to send
mail in the first place. If the mail library can’t deal with a particular
address, then it’s not worth accepting because you’re not going to be able to
send anything to it anyways.

If you have a Rails app you’re most likely using the Mail gem to send mail, so
that’s why I wrote this: <https://github.com/codyrobbins/active-model-email-
validator>. It lets the gem worry about whether an address is valid. Since the
mail library is actively maintained, in my opinion it’s a safe bet to trust
that it is properly parsing and validating addresses insofar as is possible.

------
ck2
Much more helpful:

[http://stackoverflow.com/questions/201323/using-a-regular-
ex...](http://stackoverflow.com/questions/201323/using-a-regular-expression-
to-validate-an-email-address)

and that demo email address may not be as valid as you think

[http://isemail.info/%22Look%20at%20all%20these%20spaces%20%E...](http://isemail.info/%22Look%20at%20all%20these%20spaces%20%E0%B2%A0_%E0%B2%A0%22%40example.com)

~~~
0x0
I was half-expecting the classic "zalgo" html regex parsing rant here (
[http://stackoverflow.com/questions/1732348/regex-match-
open-...](http://stackoverflow.com/questions/1732348/regex-match-open-tags-
except-xhtml-self-contained-tags/1732454#1732454) ) - but your link actually
contained a lot of helpful responses :)

~~~
jrabone
That is beautiful. And grandparent does indeeed link to the best regex ever,
<http://ex-parrot.com/~pdw/Mail-RFC822-Address.html>

------
mike-cardwell
It doesn't hurt to validate the domain part, and make sure it has at least one
MX or A record. With a bit of AJAX you can usually validate that before the
user even submits the form. Not forgetting to take punycode into account.

~~~
Flenser
You can even validate that it's a valid mailbox:

[http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-
email-...](http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-
address-exists-without-sending-an-email/)

Or use a service that will do it for you:

<http://www.freshaddress.com/demo/>

~~~
mike-cardwell
The trouble with validating using SMTP is that it is fairly likely to
introduce a delay. I still think it is better to just check the DNS, with a
very low timeout and then send the email as long as there wasn't a negative
response.

You can let the user immediately know that the email was sent, but then you
can also push updates to the user whilst they're still on the site if there is
a rejection/bounce.

I wrote <https://emailprivacytester.com/>, which does the DNS checks that I
mentioned when you enter your email address, and then keeps you informed of
the status of the message delivery as it happens, including any SMTP rejection
messages.

------
gavinlynch
Guys, I have to interject. _This is a terrible idea_ :

This is horrible practice from the perspective of a mail server. Too many
illegitimate email addresses and you will start getting more "soft bounces" (a
polite way to say, "We're not delivering this") when attempting to send mail.
ISP's keep score for how accurate a mail server is when delivering mail,
attempting to sift out spammers. When your score dips to a certain level,
ISP's stop cooperating with you and basically label you as a "dubious/bad
actor".

For a small-scale operation, perhaps this is okay. For anything larger or more
vital, I wouldn't trust this method of operation, as _it will at some point
result in emails to legitimate addresses not being delivered_. That's simply
unacceptable for many applications.

~~~
icebraining
If you get an incorrect address, it's because the user made a mistake. Chances
are, most of those mistakes will still be RFC-compliant addresses (wrong or
missing letters, for example). I find it hard to believe that people inputting
addresses without @s or with unicode characters would become a real problem.

~~~
nnnnnnnn
Frankly, your lack of belief is likely due to a lack of experience with user
submitted forms with email addresses. It's VERY common for users to simply
type the wrong data into a particular textarea. If you do no validation you
will get things like the person's name, street address, or other confused
mixups.

Anyone who deals with forms of this nature will have seen this firsthand, and
with enough frequency to cause trouble with mail relay as the person above has
described. It's a real problem.

------
kevinconroy
Although I agree with the meta-point, there's still value in doing some basic
validation. If there's no @ sign, or the domain name looks like it was
mistyped (gmali, yahhoo), then a better user experience for your user is to
present them with a warning and ask them to retype their email. You may not
want it to be a blocking warning (that is you can still submit the form), but
some validation can be a huge value add to users.

Still, sending an email beats regex validation any day for determining it's a
real, working address.

~~~
bradleyland
Yeah, skip all that too. Who says yahhoo.com isn't a valid domain?

For example, I regularly receive email for an individual who has a nearly
identical email address to my own, but at ymail.com instead of gmail.com. Any
system that tries to guess at domain misspellings is going to catch ymail.com
and think "Ah ha, they meant to type gmail.com, I'll correct that for them!"
Viola, their email is sent to me. Again, this is not a theory, it happens to
this poor guy all the time.

~~~
jeltz
Just having a simple warning should not be a problem though as long as never
do change the input of the user.

~~~
TeMPOraL
Like mailcheck.js I mentioned in other part of this thread:

<http://news.ycombinator.com/item?id=4486341>

------
mrb
Even the author of this blog post gets it wrong. Technically speaking, there
is NO need to have a dot in the domain name. These are valid email addresses:

    
    
      user@ua  (.ua = Ukraine)
      user@km  (.km = Comoros)
      user@as  (.as = American Samoa)
      (and many more)
    

Because these ccTLDs have MX or A records at the top level, pointing to real
MTAs. (RFCs say you should not have MX records at the top level, but many
ccTLDs do it.)

------
bagosm
This guy doesnt "get" UI. You are supposed to protect the user from additional
steps/mistakes,and not protect your service from the user when you use regex
to validate the email. Otherwise users could perfectly fool your best system
using billgates@microsoft.com

~~~
davidcelis
I think saying that I don't "get" UI is being somewhat presumptuous. Good UI
on the registration form can go a long way in alleviating the "switching the
email address and username fields" problem, but anything more than a check for
/@/ (or, if you're feeling ambitious, /.+@.+\\..+/) is just overkill. If I
enter a valid email address that's just typo'd, the result is the same: the
activation email bounces.

~~~
pbhjpbhj
> _If I enter a valid email address that's just typo'd, the result is the
> same: the activation email bounces._ //

No, you're excluding the set of emails that are entered incorrectly and thus
are not valid. The result for those is not the same as if the UI included a
simple test (such as your "ambitious" example).

1) Without UI validation:

\- 1.1) Email address entered correctly -> activation email sent

\- 1.2) Email address entered incorrectly but forms a valid address ->
activation email sent to wrong address

\- 1.3) Email address entered incorrectly but doesn't form a valid address ->
activation email not sent

2) With UI validation:

\- 2.1) Email address entered correctly -> activation email sent

\- 2.2) Email address entered incorrectly but forms a valid address ->
activation email sent to wrong address

\- 2.3) Email address entered incorrectly but doesn't form a valid address ->
user warned

\-- 2.3.1) Email address re-entered correctly -> activation email sent

\-- 2.3.2) other states

In the 1.3 case all of the activation emails fail to be sent. In the 2.3.1
case activation emails are sent that otherwise wouldn't be.

~~~
fhars
You are completely missing the the one case the whole argument circles around:

2.1a) Email address entered correctly -> validation fails, no mail sent

This prevents activation mails that would be sent without validation (or
validation against a regex like [^@]+@[^@]+).

~~~
pbhjpbhj
Sorry, yes, this wasn't supposed to be exhaustive just to illustrate the point
that not providing a warning on apparently erroneous email address entries was
some what pathological.

------
eli
The real problem is that lots of developers conflate validating that an email
address "looks" correct with it actually being a valid, functioning address
for that user.

There is no technical way to verify that an email address works other than
sending it a message.

And if someone doesn't want to give you a real email address, they're just
going to enter bogus@fake.com to get past the validation.

------
cygx
I'm amazed that we're still having this discussion. It's not that hard:

1\. Use regexes for client-side validation to catch typos and warn the user
against potential problems without having to round-trip to the server

2\. Check DNS records on the server side and send a confirmation mail

The client-side regular expression can be as simple as /@/, but something more
complex like

    
    
      /^("(\\"|[^"])*"|[^@\s]+)@([A-Za-z0-9-]+\.)*[A-Za-z0-9-]+$/
    

is fine - even if you mess up the regex, that's not a big deal as long as you
allow the user to send the form anyway, probably after asking if he really
knows what he's doing...

~~~
mike-cardwell
Your client side regular expression doesn't take IDNs into account.

~~~
cygx
That's because it's pre-IDN (and it fails for IP address literals as well).

This actually strengthens one of the points I was trying to make: the need to
fail gracefully. The application I took the snippet from (which has been
retired some years ago) would have accepted IDNs after asking the user for
confirmation.

------
jrabone
Article is spot on for all sorts of reasons. Never mind people typing in
domain literals like me@[1.2.3.4].

Internationalised Domain Names are going to REALLY screw over some regexes,
given how poorly understood Unicode is. Does Ruby even have Unicode regex
support yet? I don't program in it so I'm unfamiliar with the state of the
art.

On my pet topic of Unicode, I especially enjoy the use of hidden form fields
to reverse-engineer the character encoding certain browsers ACTUALLY send on
submission rather that what your code hoped for...

Good luck convincing management to Do The Right Thing here.

------
ars
Is there some rule that says you must use a regex to validate an email? Just
validate it with a more complex parser.

Alternate option: Validate it with a simple regex. If it fails ask the user
"Are you sure this email is correct?" If they say yes, then allow it even if
it fails validation.

------
yason
Email validation is a problem created out of nowhere. Sending an email, if
anything, is so cheap that it's utterly idiotic for every website to validate
the addresses instead of just sending the email to whatever the user happened
to type in the box. Either the email will be delivered or it'll bounce at some
of the hops. Think how just using exceptions instead of explicitly validating
array indexes is Pythonic.

~~~
yarrel
It's more that if I sign up and don't receive the email, you've lost a
user/customer.

------
dskang
The "send them a confirmation email" works well for registration, but there
are legitimate use cases in which you don't want to do that.

When you just want to store the email address without acting on it (e.g.,
think a landing page for an app that hasn't been released), the best you can
do is validate using a regex since sending them a confirmation email would
provide no value to the user.

------
davidcelis
Due to a huge failure on my part, I edited the title to more accurately
reflect my opinion on this. I did not mean to say that the regex validations
themselves are a waste; my point was that the complex regular expressions are
often too strict and almost always overkill.

------
Tichy
How about "stop using weird email addresses"? Just because you can doesn't
mean you have to.

How do you know you can trust a random email validator you found via Google?
Especially if apparently the rationale is to use a googled one because they
are so complicated nobody can really understand them?

That advice seems bad to me. Perhaps it is not necessary to validate and just
emailing is sufficient (as the article advises). In that case perhaps
downgrading the validation to a warning might be helpful, though ("the email
you entered looks weird, please double check").

~~~
emmapersky
I saw something similar to this once, I think it was on eventbrite. I entered
my @google.com work address for an event, and it asked me "are you sure this
is your email address" presumably because people sometimes confuse gmail.com
and google.com. I thought that was quite good.

------
bromley
I think most sites would lose far more sign-ups to a required activation email
(going unnoticed in a spam folder or sent to a typo address and assumed
delayed and forgotten) than to the occasional rejection of a legitimate email
with peculiar formatting.

Oddball email addresses probably don't last long anyway as their owners
quickly realize they can't use them to sign up for things and then switch to
something more conventional.

------
tsotha
>Some people, when confronted with a problem, think, “I know, I’ll use regular
expressions.” Now they have two problems.

It was a dumb thing to say when he said it, and it still is. Granted, REs
aren't appropriate for _everything_ , but for some problems they're the right
solution.

>So eschew your fancy regular expressions already. If you really want to do
checking of email addresses right on the signup page, include a confirmation
field so they have to type it twice.

No. Just no. I hate you and everyone else who thinks this is a good idea.
Don't make me type things twice - the point of computers is to take some of
the grunt work out of life, not to add more.

There's nothing wrong with checking an email address for validity, and there's
nothing wrong with using a RE provided it's correct. You'll miss a whole bunch
of typos, but since you're going to send out a "click to activate" mail anyway
it doesn't matter, and the ones you catch will save the user a bit of time.

------
trips2
This is like trying to tell people to stop typing

    
    
       cat file|program1|program2
    

instead of

    
    
       program1 file|program2
    

It is futile. There are so many examples of programmers just doing mindlessly
stupid things, often because "everyone else is doing it" or they read some
"howto" they found somewhere, or they are using some library written by
someone else.

How many times do you think people use extended regular expressions and
backtracking when it's entirely unnecessary? They often have no idea that
there is even a simpler way that will work (in some cases it might be faster).
They think more complexity is actually making things "easier". Must have PCRE.
Why? "Because I can't get basic regex to do what I want."

Let 'em enjoy their complex regex. Until there's a problem and they have to
try to decipher what they heck it's actually doing.

PEG is fine. Lua has a good PEG library.

Still, a good handle on basic regex will take you a long way.

~~~
rjh29
Your example is quite telling. Catting a file may be 'useless' in a pure
functional sense, but the command has extremely small overhead and aids
readability, as you can read the input/output flow from left to right. This is
consistent with the rest of the pipeline.

It's also easier to change the first command in the pipeline without having to
step over the input argument, again more consistent with the rest of the
pipeline.

To avoid the cat, one can write

    
    
        < file program1 | program2
    

but in practice, cat adds no noticeable overhead.

As for regexes, I personally find using POSIX regular expressions to be a bit
like using vi after becoming familiar with vim. You can get by, but it's crap
and there's a reason why people came up with something better. Of course,
using complicated features of any language or toolkit without understanding
how they work is dumb, but that's not a reason to go back to the 1980s.

------
dredmorbius
Holy goddamned gray-on-gray readaibility disaster, Batman!

<http://contrastrebellion.com/>

<http://www.useit.com/alertbox/designmistakes.html>

Stylish rewrite FTFW.

------
jumby
as long as I can still use something@mailinator.com, I am happy.

------
aneth4
A stronger reason: the point of validating email addresses is to prevent user
error, such as putting their name in the email field. It is not to ensure
emails are RFC compliant. In fact you probably want to allow non-RFC compliant
email addresses because there is a chance it still may work - not all servers
are going to be RFC compliant and as a product it is not your job to enforce
obscure Internet rules.

Personally I test for @ and . with any characters surrounding.

~~~
fuzzix
As pointed out elsewhere, an email address doesn't necessarily feature a '.'

Also, I learned that the local part of the address (the name) can contain
pretty much anything, including '@'

So, how would your validation handle my hypothetical, valid email address
"@foo"@bar?

~~~
aneth4
Any email address collected by a web application would have a '.'.

As I said, we are not looking for RFC compliance, but rather user error.
Missing a dot is user error in 100% of cases in a web application, unless you
are installed in and sending mail in an intranet.

As unlikely as an email with @ in the username is, the regex would still match
(something like /.+@.+\\..+/.

~~~
fuzzix
Smartass with the wacky TLD MX record and '@' user name may want to take
advantage of your service... so it's down to their monthly subscription vs
taking the time to "fix" your validation.

I'm still not sure which approach I prefer, but having been thwarted by
zealous validation in the past I lean towards this double-check-on-weird-shit-
then-send-mail system.

I will never have enough domain specific knowledge to reject a given email
address with absolute certainty. That is how much fun that RFC is.

------
lazyjones
Nowdays browsers should do the validation that provides immediate feedback to
the users (using <input type=email ...>), so the article rightly claims that
just sending an e-mail should be sufficient for the server side code. Most of
the stuff that passes the browser's input filtering will be nonexistant rather
than malformed addresses.

OTOH, most languages have proven, stable libraries for validating e-mail
addresses (e.g. Mail::RFC822::Address for Perl).

------
andrewcooke
there is a standard for validating emails. it is described in RFC 3696 -
<http://tools.ietf.org/html/rfc3696>

one implementation is in lelp - <http://www.acooke.org/lepl/rfc3696.html> \-
but that package is no longer maintained (i know, because i wrote it).

i don't know of any other implementation. but that's the right way to do it.
imho.

------
alexchamberlain
What about the security implications? You should validate input to check it
isn't malicious.

Also, no one has mentioned using DNS. For example, extract stuff before and
after the @. Check the domain looks like one and does it have an MX record? Is
the local name malicious? Send activation email. Large services should use
some machine learning for common mistakes and warn the user. (grandma@aol may
be one common error.)

------
hendrik-xdest
I don't think this will work. If you follow the RFC completely an e-mail "text
space\@moretext"@host.com is valid, as well.

Some services have two input fields for an e-mail address. The second is to
verify for typos. After that, just send the e-mail, already. If it fails you
can delete the user entry from your database and print out something in the
likes of "Who types their e-mail wrong two times?".

------
k2xl
I can't stand when I try registering for a website with my email (which has
".com" in it... BEFORE the @ symbol) as invalid. I know it's a funky email to
have, but it's valid and people often do these crazy checks.

I can see both sides though, on one hand you don't want someone accidently
entering an invalid email and then never getting their email confirmation...

------
smosher
A few years ago I would have agreed, and I still do in general. But now I'm
not sure that Perl grammars aren't up to the task and still as 'regular' as
PCRE.

However you still shouldn't be writing your own unless you're writing an email
validation module of some kind. Laziness is a virtue after all.

------
rtp
A better way is to check that the email the user entered matches a typical
email format, and if the email doesn't match, then _warn_ the user that he/she
might've entered the wrong email address (for example writing foobar@gmail, or
foobar@gmail.com __. __).

~~~
Wicher
I think foobar@gmail.com. should actually work. IIRC, that last dot is the
root of the DNS hierarchy.

Try <http://news.ycombinator.com./> ;-)

------
henrikschroder
Oh come on, does this look complex to you:

    
    
      (^[-!#$%&'*+/=?^_`{}|~0-9A-Z]+(\.[-!#$%&'*+/=?^_`{}|~0-9A-Z]+)*|^""([\001-\010\013\014\016-\037!#-\[\]-\177]|\\[\001-011\013\014\016-\177])*"")@(?:[A-Z0-9-]+\.)+[A-Z]{2,6}$

~~~
ch0wn
And yet it's not enough. According to the standard,

"my@scary$doublequoted.address"@example.com

is a valid address.

------
taxonomyman
I rememeber back in the day when email addresses like hello@[8.8.8.8] were
valid..

------
trebor
I've taken to checking if the domain of the email has valid MX records. That,
and a very rudimentary regex expression (not quite as simple as the OP's
though) seem to do the trick well.

------
acabal
PHP coders can use the simple built-in filter_var function:
<http://phpbestpractices.org/#validating-emails>

~~~
nickzoic
Yeah, and there's a Perl Email::Valid <http://search.cpan.org/~rjbs/Email-
Valid-0.190/> which checks for well-formedness and the existence of the
domain.

------
mildweed
The way that a perfect regex was found:

[http://fightingforalostcause.net/misc/2006/compare-email-
reg...](http://fightingforalostcause.net/misc/2006/compare-email-regex.php)

------
pbreit
The solution the OP proposes (validating email addresses through a clicked
link in a "welcome" email) is pretty user hostile and unnecessary for most
services.

~~~
gradschool
True. It would be fair enough if I were signing up for a mailing list, but
it's rarely clear to me as a user why any web site wants my email address. Is
it to send me emails reminding me to check the site? Is it to help me "keep in
touch" (with my new friend do-not-reply@morons.com)? Is it just standard
practice taught in web-dev school? Am I being overly cynical to think someone
is trying to turn my inbox into a billboard, that we both know I don't want
that, and that the confirmation link is used to stop my little brain from
outsmarting him with a bogus address? What do those of you on the other side
of this issue think about it?

~~~
pbreit
A good reason to verify ownership of an email address is, for example, PayPal,
where money is actually attached to an email address.

------
nemetroid
This misses the point entirely. The point is rarely to avoid fake email
addresses, but to make sure they don't contain spelling errors.

------
moheeb
Nobody does a domain lookup to test validity?

------
propercoil
no thank you. i'll stay with ^[\w.]++@[\w.]+$

~~~
bittermang
That doesn't validate user+tag@gmail.com, which is one of the very root points
that he was trying to make in the first place.

------
derleth
Here is an interesting list of test cases, some of which parse as valid email
addresses and some of which do not. If not, the page says why:

<http://isemail.info/_system/is_email/test/?all>

For example: !#$%&`*+/=?^`{|}~@iana.org is valid.

Here's an essay on the subject:

<http://isemail.info/about>

