History:Implementing Email Communications

Status: This Page is Glorious History! The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.

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 email addresses as a form of communication; in the first instance, to allow moderators to communicate on moderation issues.

Confirmed Email Address Registration

So far the email 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 email 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 email address as normal. Set emailconfirmdate to NULL
  • enforce that the email address is either blank, or "looks ok" (e.g. something a bit looser than ^\w+\@\w+(.\w+)*$)
  • do we still allow blank email? Or shall we insist on a valid email address?

• send confirmation email to the cited address
  • the email message includes a web link back to MB, e.g. /user/confirmaddress.html
  • the web link includes query string params for user ID, new email 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 email address:

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

• system sends email 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 email 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 email 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 email 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 Email (once the above is implemented)

Password reminder

Given username only, email a web link to the user's email 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 email the user's password to them.

In both cases, if the user email 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 emails. I was thinking more like just whenever a mod is inserted; again, optionally with a daily digest. - DaveEvans