No, an MX lookup doesn't prevent that -- but the SMTP checks that Mail::CheckUser provides often can. Mail::CheckUser has the option to do an SMTP conversation with the MX, doing HELO, MAIL FROM, RCPT TO, response check, and QUIT. If there's no MX, or the MX tells you that it won't accept mail from you or for that user, you're better off knowing early enough in the process that the user can correct the problem.
I can see no good reason to task my SMTP server with caching, retrying, and ultimately returning undeliverable messages whose addresses could have been corrected by the user very early in the process.
Again, in e-commerce, it's important to ensure that users who are expecting email actually receive it. The alternatives are expensive: telephone calls and/or lost customers. It's important, I think, to support those lousy typists with valid credit cards. | [reply] |
Well you've at least shed some light on the theory behind it. It would seem then that you are more trying to catch typo's in peoples email addressess rather than stop evil doers. I still wonder if your assumption that it is better to do a sort of fake transaction early is better than just doing a real transaction with retries etc. It seems like you are then just trying to side step the RFC and skip any retry mechanisms when in fact there could be valid reason you couldn't send an email now and you would be able to 10 minutes later. In those cases you are now complaining to users with valid email addresses. It would seem then that you are going to get false positives for people with real addresses that are full and evil doers (although i know your goal wasn't to stop them at this point) can just pick random emails and get through. That's why I don't see the merit. the only point I can almost see is if you have such huge volume that the retries on invalid accounts would bring your mail server to its knees and I would guess the volume would have to be quite large to cause that, but then perhaps I am wrong.
| [reply] |
Typos are the primary motivator, true.
It's not side-stepping RFC2821 so much as it is working around the widespread switching off of VRFY support, which is a response to spammers abusing VRFY. Mail::CheckUser provides a mechanism that, by default, does not treat a full mailbox as a failure, and the docs suggest against treating a timeout as a failure. What I do in response to timeouts is explain to the user that his address could not be validated "due to temporary network congestion", and bother him to confirm that it's correct. After that, the SMTP server gets to cache and retry as necessary when it's time to actually send email.
I've yet to hear a complaint from a user with a valid email address which has been rejected by these kinds of checks. It's certainly possible that a user could happen along while his DNS administrator is experiencing a fit of incompetency and there are no MX records to be found -- frankly, I consider this to be in the "Not My Problem" category. I'm not aware of it happening yet on any of the sites I administer, but if it becomes a recurrent problem I suppose I'll have to deal with it somehow.
| [reply] |