The only E-Mail validation involves sending an actual email with a response link.<p>Because even if people happen to give you a <i>functional</i> email address, it isn't necessarily <i>their</i> email address.<p>And I say that as someone who has come to regret registering a first-initial-last-name gmail address. And it's not even a particularly common last name.
This is just awful. A quick scan of the code brings up the following problems:<p>* It fails to deal with the case where there is no MX record for the domain (fall back to A record)<p>* It fails to sort the MX records, potentially falling foul to tarpits<p>* It fails to connect to each A record lookup of the MX host on failures<p>* It fails to deal with transient failures (such as 4xx responses)<p>That was just from a quick scan.<p>Connecting to MX servers in a web environment (especially one using blocking I/O like Django) is generally a really bad idea. Many MX servers use delays and slow responses to combat spammers, and you're passing those slow responses on to your users.<p>Just check it looks vaguely like an email (the regexp fein posted is good enough most of the time) and send a confirmation email - it's the right thing to do.
And I'll still give you fakeaddress@mailinator.com, it will pass every check you can throw at it, including sending an email and getting me to click a link, and it still won't be a <i>real</i> email address.<p>Still your move, e-mail harvesters.<p>Checking that I haven't mistyped it or put the wrong thing in the wrong field is a basic sanity check. Beyond that, the only way to actually get a real email address that I read is to <i>be a service I care about</i>.
Making your app connect to random SMTP servers every time it needs to validate an email address doesn't seem like a good idea.<p>Shared domains (gmail.com etc.) might even get you blacklisted if you flood the same SMTP servers over and over again.
The best way to improve email delivery is to understand that email addresses represent humans. Address validation and long-term deliverability is primarily a problem of social engineering, not technical.<p>Ordinarily I'm in favour of things that can improve data quality with minimal user friction, but in this case while it looks like an attractive solution, it's both dangerous _and_ broken.<p>It's dangerous because if you repeatedly open empty SMTP sessions with major ISPs (and some neckbeard boxen) to validate addresses, you will rapidly fall onto blacklists. Furthermore existence of an address says nothing of the end user's ownership of that address.<p>It's broken because of the myriad crazy responses that mailservers return -: 5XX errors for soft-bounces, 4XX errors for permanent failures, deliberately dead primary MX server...
The web's email infrastructure is so massively fragmented and quirkily non-RFC-compliant you just cannot rely on technical solutions to these problems except at scale of an ESP (disclaimer: I work at PostageApp.com, a transactional ESP, and we tackle this problem on a large scale)<p>Finally, it fails my 'Spammer Sniff Test': If you think of a clever trick to improve email delivery/opens/responses etc, it's been thought up 10 years ago by spammers and long since added to blocked behaviours in email protection infrastructure.<p>Check for '@', and craft your email verification process to incentivize following through. For long term delivery (to bypass the mailinator issue) provide value, pure and simple.
Greylisting is pretty common, and this would obviously fail:<p><a href="http://en.wikipedia.org/wiki/Greylisting" rel="nofollow">http://en.wikipedia.org/wiki/Greylisting</a>
As an aside, would there be some value in providing an email validator API?<p>Something exactly like this:
<a href="http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate" rel="nofollow">http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate</a><p>but which would respond in an easy-to-parse way (JSON|XML).<p>It could be enriched by detecting common spelling errors ('gmial' or 'g-a53'* instead of 'gmail' for example).<p>*: gmail when typed on a European laptop with numlock on.
('SMPT' is used throughtout instead of 'SMTP'.)<p>What does django.core.validators.EmailValidator actually do?<p>Validating an email address with a regex is surprisingly hard: see <a href="http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html" rel="nofollow">http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html</a><p>I wonder if EmailValidator does this, or something simpler?
This is pretty awesome! Wonder how much time would it take to validate. Last thing I would want is to make that signup process even slower. I guess you could still let the user pass and then run an async task to check "if the domain name exists, ask for MX server list from DNS, and verify that SMPT server will receive a message to that address" and then maybe set a flag somewhere.