Actually I think the default answer for this is "Send a confirmation link to the email", because you skip almost all the impossible edge cases, like "catch-all address" or using public e-mail address or whatever.
Most important question you have to ask yourself is "What do I want?". If the answer is "This user e-mail address.", there isn't better way than sending a confirmation email.
Absolutely. There simply isn't a reliable lookup method.
As I pointed out elsewhere, there are plenty of e-mail systems that won't tell you whether or not the address exists until after you've submitted a valid-looking e-mail anyway.
According to http://www.greenend.org.uk/rjk/tech/smtpreplies.html, SMTP server can give you either a temporary error (452 - Requested action not taken: insufficient system storage) or permanent error (552 - Requested mail action aborted: exceeded storage allocation). Maybe there are some heuristics that are used for this...?
Nothing, but it's also too slow, and pointless for them: It's easier for them to just send. Many of them clearly don't even care about checking response codes, or retry after greylisting, which is why these techniques works (greylisting cut our spam volume by about 90% off the bat).
But there's also no guarantee that the remote server will reject the address until after you've actually submitted a full e-mail, and send the final "." , exactly to make it even more expensive for spammers, in which case any attempt at checking short of actually sending an e-mail will fail.
Their suggestion may give you an indication, but if you try to rely on it you'll get a lot of pissed off users.
On a an unhardened SMTP server, nothing. But there's not a huge amount of value for them in sanitizing those lists either, as they already deal in such high volumes of mail a few retired accounts don't matter. There are anti-spam products from places like GFI that can apply heuristics to incoming requests and filter out anything suspect though.
The bigger risk is directory harvest attacks, where spammers dictionary generate RCPT TO requests and use any 250/251 replies to compile new mailing lists.
Tarpitting combats this to some degree and is considered best practice when allowing RCPT replies. The receiving server is configured to pause for a few seconds before replying to each RCPT TO. 5-10 seconds is fast enough to not impact mail flow while rendering dictionary based directory harvest attacks non-viable.
Send a mail. If it bounces, ignore that. If someone takes an action based on the content of the mail you sent, the address is valid. I'd say this link is bad advice.
This is answering the question: "Does tihs email address exist?", which is nice, but usually not the question being asked. The more common question is "Is this the email address of the user", which can only be answered by a confirmation email.
You could use this method as a first-line validation though, to give the user some feedback (similar to not implementing the full RFC regex, but simply checking /.+@.+\..+/)
10 comments
[ 3.3 ms ] story [ 26.1 ms ] threadI understood the default generic answer to this was "send an email to it, through a mailing service you pay for, not through your own infrastructure."
Most important question you have to ask yourself is "What do I want?". If the answer is "This user e-mail address.", there isn't better way than sending a confirmation email.
As I pointed out elsewhere, there are plenty of e-mail systems that won't tell you whether or not the address exists until after you've submitted a valid-looking e-mail anyway.
But there's also no guarantee that the remote server will reject the address until after you've actually submitted a full e-mail, and send the final "." , exactly to make it even more expensive for spammers, in which case any attempt at checking short of actually sending an e-mail will fail.
Their suggestion may give you an indication, but if you try to rely on it you'll get a lot of pissed off users.
The bigger risk is directory harvest attacks, where spammers dictionary generate RCPT TO requests and use any 250/251 replies to compile new mailing lists.
Tarpitting combats this to some degree and is considered best practice when allowing RCPT replies. The receiving server is configured to pause for a few seconds before replying to each RCPT TO. 5-10 seconds is fast enough to not impact mail flow while rendering dictionary based directory harvest attacks non-viable.
Send a mail. If it bounces, ignore that. If someone takes an action based on the content of the mail you sent, the address is valid. I'd say this link is bad advice.
You could use this method as a first-line validation though, to give the user some feedback (similar to not implementing the full RFC regex, but simply checking /.+@.+\..+/)