History:Implementing Email Communications

Status: This feature has been implemented in MusicBrainz server. This page will be kept for historical purposes.

This page describes the work necessary to be able to use moderators' registered e-mail addresses as a form of communication; in the first instance, to allow moderators to communicate on moderation issues.

Confirmed E-mail Address Registration

So far the e-mail addresses in MB (moderator.email) are just single line free text. The data in there so far presumably includes completely valid addresses, faked addresses, things which aren't addresses but which represent them (e.g. "x at y dot com"), random meaningless text, and of course blanks.

What we need to do is to implement a confirmed registration system, and then attempt to migrate the existing "email" column - whatever it contains - to a confirmed e-mail address.

Confirmation System

I think the following new moderator columns are needed, or at least useful:

• emailconfirmdate - date/time the email address was last confirmed, or null for never confirmed

For new users:

• register and enter e-mail address as normal. Set emailconfirmdate to NULL
  • enforce that the e-mail address is either blank, or "looks ok" (e.g. something a bit looser than ^\w+\@\w+(.\w+)*$)
  • do we still allow blank e-mail? Or shall we insist on a valid e-mail address?

• send confirmation e-mail to the cited address
  • the e-mail message includes a web link back to MB, e.g. /user/confirmaddress.html
  • the web link includes query string params for user ID, new e-mail address, time sent, and a checksum (tamper-proofing)

• the user then clicks the web link to confirm their receipt of the message
  • the confirmaddress page then checks the checksum against the other parameters
  • checks the time sent (the link expires in e.g. one week to prevent replay attacks - at least, really old replays)
  • sets moderator.email to the email parameter
  • sets moderator.emailconfirmdate to NOW
  • shows a confirmation message
  • If something goes wrong, e.g. checksum or timestamp failure, show appropriate message

When a user wishes to change their e-mail address:

• enter new moderator details on form as normal. Save all details except email address.
  • e-mail field validates as for new users

• system sends e-mail containing web link as for new users. Message is sent to the new address.
• changeaddress page operates as before

For existing users, we need to validate their existing moderator.email values:

The easy option: we could just tell all moderators that, next time they log in, they should go to their "profile" page and re-enter their e-mail address. Then follow the rules as for "changing address", above.

• How about we ask the moderator to verify their email if they have an unconfirmed email addy after they log in? We can also give them the option of removing the email addy. Ruaok
• OK, but what state do they start off in? Do you just leave them all as uncomfirmed (the above option) or try to confirm them automatically as part of the data migration process (the below option)? DaveEvans

Or, we try to send the "change address" message automatically to all existing moderators. We might want to send it only to addresses which "look valid".

Most of the above stuff has now been implemented. I'll finish off the remainder of the stuff in the am and check it into a branch. Ruaok

Optional Features

Automatic re-verification of addresses (identifying stale addresses):

• two extra columns: lastverifysent and numoutstandingverifies
• when emailconfirmdate becomes sufficiently old (e.g. 3 months), and when lastverifysent is also not new (e.g. 1 week), then:
  • if numoutstandingverifies is high (e.g. 3) then we can no longer contact the user. Blank out their e-mail address and/or mark as not valid (i.e. set emailconfirmdate to NULL)
  • otherwise, send out a "please click this link to confirm your address is still valid" message, and increment numoutstandingverifies
  • when the web link is clicked (user ID, email address, time, checksum as before), set emailconfirmdate=NOW, numoutstandingverifies=0

I don't think it matters for MB to have correct email addy's at all times. It only really matters if the user is subscribed to something or moderating. Perhaps we should check to see if users have a valid email when they enter a moderation? Ruaok

It certainly makes sense not to bother checking for someone who never logs in. Maybe we should have a "lastloggedin" datetime field, and only perform the above checking for users who have logged in recently (say, three months). - DaveEvans

Reply via e-mail instead of (or as well as) web link

• as well as a web link (as described above), formulate a special "reply-to" address (including user ID etc) so that the user can just reply to the message to perform the activation

Ways of Using E-mail (once the above is implemented)

Password reminder

Given username only, e-mail a web link to the user's e-mail address. Web link includes checksum, time, etc. The page at that link allows the user to change their password without having to know the old password.

Or, even simpler: just e-mail the user's password to them.

In both cases, if the user e-mail is blank, show a "we can't help you" error message. What if it's unvalidated? Just send the message and hope for the best? - DaveEvans

Mod-to-Mod Email

tbc

Moderation note Email

When a moderator gets a note to one of their moderations. the modbot sends a note to the moderator.

Subscribed Artist Email

A moderator is notified when a new moderation has been entered or a moderation has been closed for one of the artists they subscribed to.

• opened and closed? That could be a lot of e-mails. I was thinking more like just whenever a mod is inserted; again, optionally with a daily digest. - DaveEvans