in reply to Re^6: Yet Another E-mail Validation Question
in thread Yet Another E-mail Validation Question

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.

  • Comment on Re^7: Yet Another E-mail Validation Question

Replies are listed 'Best First'.
Re^8: Yet Another E-mail Validation Question
by eric256 (Parson) on Apr 22, 2005 at 16:28 UTC

    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.


    ___________
    Eric Hodges
[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]

        One of those cases where it is usefull to know how it actualy works in eperience agiansn't the realm of the possibilites. So it sounds like for that particular goal it does the right job. Thanks for the info. I think if you are going to send emails that a emailed verification code would still be best because it means most you are sending 1 unwanted email to someone. I'm guessing however that you use that as well and just use Mail::CheckUser to verify the address might be an address, then use further means to make sure it the right users address.


        ___________
        Eric Hodges
[reply]

In Section Seekers of Perl Wisdom