in reply to Re^3: Mail::Verify or Mail::CheckUser for Email Verification?
in thread Mail::Verify or Mail::CheckUser for Email Verification?

Thanks for your reply, ww.

I used the word 'ping' as I can't seem to find a one-word description that better explains determining the existence of an email address without actually sending an email message.

If I were to integrate email verification now, is there an free open source software or script that you could suggest?

Thanks.
  • Comment on Re^4: Mail::Verify or Mail::CheckUser for Email Verification?

Replies are listed 'Best First'.
Re^5: Mail::Verify or Mail::CheckUser for Email Verification?
by ww (Archbishop) on Jul 08, 2010 at 02:58 UTC

    Perhaps other monks have wider experience/knowledge of ready-made software.

    As for me, I don't know the code currently you're using... but I probably wouldn't tackle the issue using third party software, anyway. Rather, IMO, the process several of us are advocating -- integrated email verification -- is one I would tackle from scratch, whether as additional code for your extant package or as a module.

    Many of the details here can be modified to suit your preferences and requirements, but here's a possible workflow:

    1. The user submits your registration form
    2. your cgi (the form's action)
      • assigns the request a unique ID
      • stores that and the user's email (and other data?)
      • sends an email with the ID to the address supplied.
      The email (and, preferably, the registration page as well) explains that the user must reply (within a short time limit -- definition of "short time" left to you) to an email account you control to confirm the account request.
    3. A second script (or, for a really low intensity operation, a human) monitors incoming mail on the specified account, intercepting those with whatever subject line you assign to your initial outgoing mail.
    4. The second script compares the ID (plus address, name, etc, as your please) in the incoming email with the data stored by the cgi.
    5. If they match, the second script blesses (creates, calls a creator script, whatever) a new account.
            } else {
    6. ...if there is no match, second script takes no action...
            } but {
      periodically, second script reviews aging account request info (as stored in step 2) and kills those which have timed out.

    Updated formatting for clarity

      Thanks again, ww.

      That makes perfect sense to me. You've spelled it out so nicely, too. I can work with that.

      Thanks so much!