I mean, obviously unless you are writing an MTA or whatever.
The first assumption is that your intent is to capture accurate user information and the user's intent is to give it to you.
With that established, it is a good idea to apply sensible measures at your end in order to ensure that the data is accurate.
Then there's the reduction of junk signups and the like. This is a case where your user doesn't necessarily have to know that you are validating. You can simply tag the signup as potentially invalid in the database and require human inspection or discard it if there's enough information to do so. In other words, the validation happens in the server and with no feedback to the client.
The RFC822 regex expression will pass something like this as valid:
joe @example.com
joe@ example .com
joe@example.ccom
joe@example.com-
joe@example.com----------------
joe@example.com/////
You can check it yourself here:http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate
I haven't done exhaustive testing on that particular expression. I don't really know where it fails. And that's part of the problem.
If the "contract" is that both parties want this information to be correct the user couldn't possibly be annoyed if you point out a legitimate error in the email address. You can prevent a situation where someone fills out a form, clicks "send" and goes away thinking that the signed-up when they actually didn't because they made a mistake entering their email address. What are you going to do? Send them an email?
Obviously, if they enter
jjoe@somedomain.com
instead of joe@somedomain.com
The only hope you have to catch it is to make them enter it twice and hope they don't make the same mistake twice. This is ugly and bad for such things as landing page signup forms. People don't generally respond well to having to type their address twice.So, yes, even with validation you are going to loose a few.
What you are going to catch are cases where the email is entered with detectable mistakes:
jot dot@somedomain.com
jotdot@@somedomain.com
jotdot@somedomain.com.
jotdot@ somedomain.com
jotdot@somedomain..com
jotdot@ somedomain.comm
etc.
instead of jotdot@somedomain.com
With a good email validation approach --which includes DNS checks-- you can catch most of these and alert the user. I don't think this is a bad idea at all.While it is true that that super-large regex expression seems to validate most addresses correctly, there's a voodoo out there in the realm of regex for email validation. Buyer beware.
An absolute FQDN ends with a period:
apple.com.
A relative FQDN does not: apple.com
When a DNS resolver sees an absolute FQDN it has a pretty direct path to getting the corresponding IP address.If, instead, the resolver is looking at a relative FQDN it does not, and it tries to fix it, and it could go around in circles for a while depending on where the resolver is running. What the resolver does is add different forms of DNS suffixes it has available until it either figures it out, fails or times out. For example, if the resolver is running on www.example.com, it might try the following:
apple.com.www.example.com.
apple.com.example.com.
apple.com.com.
If it finds any CNAME records it will follow them and go around in circles some more. I ran across this recently while looking at the whole issue of email validation through DNS. So, this is fresh pain you are hearing about!Here's my post on SO:
http://stackoverflow.com/questions/14065946/what-would-cause...
I also have a DNS function test page on one of my sites here:
http://www.tommyteaches.com/test/test2.php
If you try a domain like "notarealdomain1.com" you'll see that it takes a while (20 to 30 seconds per test) for the DNS functions to resolve it. If, instead, you enter "notarealdomain2.com." (period at the end) the DNS resolver will come back almost immediately. This is due to the DNS suffix append mechanism described above.
Note that if you enter the same name twice, the second test will return faster due to caching.
Here's an interesting read:
The more trivial the better (something like .[star]@.[star] ([star] == *, HN formatting bites sometimes)); people going too clever with validating e-mails (like if there was a good reason for doing that) end up rejecting + sign in the address as invalid, which is incredibly annoying for GMail users.
Use something like `^([^\s]*)@([^\s]*\.[^\s]*)$` which will do most of the work for you, then check second group for common domain typos, and what have you.
I don't understand. How does this expression do anything even remotely close to email validation?
For example, how does it tell you that:
These are valid:
test@nasa.gov
~~~~@nasa.gov
joe+sometext@nasa.gov
test@bbc.co.uk
and that: These are NOT valid
test@example.com (no MX RR)
test@-nasa.gov
test"@nasa.gov
test@nasa.gov-
test
test@nasa.rockets
test@bbc.co..uk
test@bbc.com.uk
test@bbc.co.eu.uk
You'd have to write all the validation logic yourself all over again. And that's just a few examples.Barring anything else, the RFC822 expression isn't so bad that someone should replace it with the kind of thing you are suggesting.
Sorry if I don't see it.
The best way to validate an email address is to send an email to whatever address is supplied to you, if it is a true email address the user will receive an email and it will be validated, if not then their account or query will go unused/unanswered and that will be down to them.
Multiple reasons, and, yes, context is important.
Landing Page: You have one, and ONLY ONE, opportunity to capture a potential new customer's contact info. If they make a mistake entering their email and you didn't catch it you'll loose them forever. You can't send an email to let them know they entered two periods by mistake, can you? They are gone and you screwed-up.
Every single potential customer is sacred. Thou shalt not loose them by being careless.
Forum signup: In general terms, if someone is visiting a forum it probably means that they want to sign-up. In this case, it is OK to make them enter their address twice, make sure they match and send them a confirmation email. They'll probably try to log-on later on and discover something went wrong and re-register.
While I said "that's OK", I also think it is bad form not to at least do enough validation of all input data, including email, to catch innocent mistakes. I think people who are against email validation might have that position because they don't understand it or gat bitten by a crappy regex expression and that is that.
Now your forum sign-up user is angry because they have to enter all of their information again and go through the process one more time. Who knows, they might make a mistake once again. While I don't have any data to back this up I would venture to guess that the drop-off rate for making a visitor enter all of their data multiple times is significant.
Payment Confirmation: Must check as much as you can.
From my vantage point taking ANY action that might loose or annoy a visitor is simply --to be kind-- programming. There's no excuse for that in my book.
About the invalid cases, who cares? It's not a problem, you must send an e-mail to check for correctness either way:
your user may
* wrongly type his e-mail e.g. bil.gates@microsoft.com
* write on purpose a valid e-mail of another person e.g. yourbestenemy@gmail.com
* write a grammatically valid but nonexistent address
* forget how to access his own e-mail address
You must always send a mail to confirm his validity, so if you have some false positives there is no harm, and it's faster to validate too.
Sorry, that's not a good reason to use this. If you use the correct approach you will NOT filter out syntactically correct emails and you WILL catch all invalid addresses that can be detected syntactically.
It just isn't a good idea to use this expression in place of the RFC822 expression. And, keep in mind, I am not a fan of the RFC822 expression.
With regards to your other scenarios, please read my reply to "rawb92" here:
http://news.ycombinator.com/item?id=5003032
In a nutshell, if someone enters a malformed email address by mistake and you don't catch it, it's game over. What are you going to do? Send them an email?
The spammers and tricksters will always exist. You'll have to decide how to deal with them yourself. In other words, stuff like someone attempting to sign-up their buddy to a porn site. That's got nothing to do with email validity, that's a matter of identification, and, yes, in that case the first line of defense is to send out a confirmation email.
You can use something like Mailcheck.js [0] for that client-side; it'll help weed out a lot of domain typos.