Fixing typos in user-entered email addresses
We see some typo domains in our mail queue from time to time and I have been thinking of using our internal DNS server to correct these people's mistakes.
Some examples from the current mail queue:
g-mail.com
hotail.com
hotmai.com
hotmaiil.com
hotmal.com
htomail.com
rediffmai.com
yahii.com
The above domains do not have MX records but it's easy to see what the user meant when they typed it in.
The emails in question are often signup confirmation emails so the user can't login and fix their own email address and running a cron job that fixes it in the database won't send out the confirmation email again.
Setting our internal DNS to resolve these MX lookups to the proper Hotmail, Gmail or Yahoo (or whatever) addresses would most likely result in the mails ending up in the correct inbox. A cron job could also correct their email address in the database.
The best solution would be to do the MX lookup in the signup/email verification code on the web server so we can give the user an error message while they're still on the site but I'm a sysadmin and I can't get the dev time approved for this.
Can anyone see any potential problems with redirecting typo emails using DNS ?
Update:
I thought of a problem that potentially scuttles this whole idea. Assuming we do correct the typo domains using DNS, when we connect to the target mail server we're going to (at some point) say:
RCPT TO:<[email protected]>
And the Hotmail server is probably going to reject it because they don't accept email for hotmal.com and they don't relay mail for me. The problem is that we haven't fixed the address. All we have done is pointed our MTA at the correct server as if we had the correct address.
I also found this mailing list archive which has a different solution to the typo domains. It doesn't solve my problem with letting the users know but it does get the mails out of my mail queue very quickly.
Solution 1:
The biggest problem will be false positives - i.e. those typos that you correct to the wrong domain.
Using a typo that probably wouldn't happen you might get:
gotmail.com
do you change this to
hotmail.com
or
gmail.com
The user could have meant either.
It's far simpler just to bounce these back to the user with a "domain not recognised" message and let them make the correction.
Solution 2:
I can't see the problem you are trying to solve. You want to send signup confirmations. But as you can't send signup confirmations to domains that do not exist, there will be no signup. That's OK. Drop the user that couldn't be confirmed and let them sign up again. That's how it goes. This is called Double-Opt-In and is a MUST for verifying Email addresses.
Normally these mails shouldn't even be in the queue:
- If the domain does not exist the mail should bounce immediately (time to drop the user instantly).
- If the domain resolves but reaches a non-existent user the mail bounces immediately (time to drop the user).
- If the domain resolves but the server temporarily defers the mail you can't decide if the mail will be delivered later or is an invalid address (time to wait for option 2 or 4)
- If the domain resolves and the user is valid, the mail will be delivered instantly (time to wait for confirmation, but the mail is out of the queue)
Solution 3:
I agree with ChrisF about the false positives. Lately I've been working with email addresses pulled out of our ERP system and have come across many problems. Just as an example, one of our major ISPs is Optus. As I recall, based only on what is not bounced back, their email domains can be any of
- optusnet.net
- optusnet.com
- optus.com.au
- optus.net.au
- optusnet.net.au
- optusnet.com.au
... and possible others I don't know of.
If I see one that is invalid but looks like it should be an Optus address do I just take a wild guess at which one is correct? After all, it might be any one of those, or none none of them.