in reply to Yet Another E-mail Validation Question

EDIT: Rewritten slightly to make my meaning clearer.

I would use a combination of double email fields (it isn't as irritating as you think), server-run email verification with hash link, and user-run email verification via hash code included in the body of his email. The latter method would be described under "Didn't get your verification email?" and would basically consist of the user emailing a specified hash code to your verification address from the email the user signed up with. All you need is a script that can run through the contents of your email box every so often, matching email addresses and hash codes to unverified user accounts.

Of course, if your email system blocks their email as well, then they're stuck. But this isn't nearly as likely.

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

Replies are listed 'Best First'.
Re^2: Yet Another E-mail Validation Question
by deibyz (Hermit) on Apr 21, 2005 at 07:51 UTC
    The latter method would be described under "Didn't get your verification email?" and would basically consist of the user emailing a specified hash code to your verification address from the email the user signed up with.

    I don't like this method too much. Mainly because from a personal mail server I can send a mail with "From:" equal any mail if I want, so with this method I could subscribe and confirm any user I want, and I think this is not a very good practice.

    The thing with bounced e-mails is that an valid working e-mail can still bounce due to a error such as full mailbox. If the e-mail does bounce, is there anyway I can make my perl script notify the subscriber through html?

    It depends on the configuration of the remote mailserver. Maybe it's throwing 4xx error when user mailbox is full and 5xx when user doesn't exist, or maybe it's accepting anything and sending DSNs, or maybe... I think you shoul only send the mail, and then the user should worry about why it didn't got delivered.