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

I'm guessing that you don't mean "ping" to be taken literally in "ping the email address" because that's not what ping does. It may be feasible to ping the email server you're checking up on, but I've never heard of any way to ping an account ( - :-) - that admission may even prompt some wiser and more knowledgeable soul to post code to refute my belief!).

So maybe you should think about finger or another appropriate tool.

But,just as "cutting off the dog's tail by inches" is unnecessarily painful for the dog, I suspect verifying the existance of any particular email address -- EXCEPT BY requiring the owner to respond -- is going to be far more painful for you and your organization than "just doing it right in the first place;" i.e., "have email verification integrated" now.

As to downsides to the ping scheme, they include

  1. delay
  2. failure
        and, of course,
  3. the inadequacy of that method of determining the validity of the email address used for account creation.

Replies are listed 'Best First'.
Re^4: Mail::Verify or Mail::CheckUser for Email Verification?
by newbie00 (Beadle) on Jul 08, 2010 at 02:09 UTC

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

      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

[reply]

        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!

[reply]

In Section Seekers of Perl Wisdom