3 ms·
It's a good approach because it doesn't filter out grammatically correct e-mails while blocking the blatantly false. About the invalid cases, who cares? It's n
by riquito 14y ago
It's a good approach because it doesn't filter out grammatically correct e-mails while blocking the blatantly false.
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.
- robomartin 14y ago> It's a good approach because it doesn't filter out grammatically correct e-mails while blocking the blatantly false. 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 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.