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

Oh! In that case... yes, users do often enter their email addresses incorrectly into forms. Others, for whatever reason, will trust you with their credit cards, but not with their email addresses. Odd, but it happens.

If you're doing e-commerce, you want to ensure that you can, in fact, contact the customer if there's a problem with the order (or payment for it). If you're running a mailing list, especially if it's a large one (as promotional lists often are), it's just good practice to minimize bounces. Some mail system administrators get grumpy if you fling too many invalid addresses at their servers -- who could blame them? It's sometimes hard to tell innocent errors from dictionary-attack spamming or joe-jobbing.

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

Replies are listed 'Best First'.
Re^6: Yet Another E-mail Validation Question
by Anonymous Monk on Apr 22, 2005 at 08:38 UTC
    Some mail system administrators get grumpy if you fling too many invalid addresses at their servers -- who could blame them?

    And checking for whether the mail server exists prevents this? I'd be surprised.

    Trying to send out an email to a host for which there isn't an MX record won't anger any postmaster (except perhaps your own), as no mail will get delivered. And if it's going to hammer a DNS server, enable caching. ;-)

[reply]
      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.


        ___________
        Eric Hodges
[reply]

In Section Seekers of Perl Wisdom