EmailVerificationFeature

This page described a possible new server feature.

Aims:

The implication of (2) is that if the user doesn't re-verify their address in time, it will be disabled (see below).

Assume that the fate of each email is exactly one of bounced/not-received/ignored/read. (2) verifies that, at least for the verification emails, they are "read". (1) is to verify that "not too many" emails get "bounced".

You could argue that (2) makes (1) redundant; if you assume that all emails sent to any given address meet the same fate (e.g. they all bounce, or they all get read), then (2) verifies that the answer is "read", therefore bounce detection is not needed. However it's likely that (2) will probably ask users to re-verify maybe once every 6 months, whereas it's probably desirable that (1) disables a dead address much quicker than that.

Periodic re-verification

Start by setting email_expiry_date of all users (with non-blank email addresses) to: MAX(1 month from now, (signup date + 6 months)). email_last_verify_sent will be null.

Whenever the click back occurs and the address is written to the user's record), set email_expiry_date to now + 7 months.

Whenever a verification email is sent, if the target address matches the existing stored email address (i.e. we are re-verifying their existing address), update email_last_verify_sent to now.

Nightly (?) cron job:

Removal of dead addresses

Much harder. Would need to be based on handling incoming bounces (i.e. use unique encoded sender address?).

Could configure local (www server's) MTA to not verify RCPT, i.e. instead of rejecting RCPT just bounce the message (therefore avoiding duplicated code).

However this is likely to be problematic - see Mailman.

last edited 2008-02-17 19:35:59 by otis

MusicBrainz web site  *  Support / Contact