Thanks to everyone for the input on this. I wrote a revision of the proposal. It's on https://dev.launchpad.net/LEP/BounceHandling and the meat of it is below. Thoughts still welcome! (Though I do hope we're narrowing down on agreement.)
Thank you Gary === Must === User Experience * We send normal Launchpad emails to each user's preferred email address, as we do now. * If a preferred email address bounces "too much" for our heuristics (as informed by Barry's Mailman experience), then we do the following. * We move the user's account into a state that means that their preferred email address is disabled. In this document, call this the DISABLED PREFERRED EMAIL state. We'll describe what this state means to the user below. * We send an email to all of that users' registered & validated email addresses, including the one that has bounced, informing them that their preferred email address has a problem. Describe the symptoms and how to address the problem (see below for details on both). * As long as a user is the DISABLED PREFERRED EMAIL state (that is, as long as a user's preferred email address is disabled), we do the following. * We do not send any normal Launchpad emails to this user. * When a user views their registered email addresses, they can see what addresses have been disabled due to bounces, and reenable them, in addition to setting preferred email and adding and removing addresses, as they can do now. Reenabling their preferred email address (and thereby leaving the DISABLED PREFERRED EMAIL state) can be done by changing their preferred email address to an address that is not disabled, or by declaring that their current email address should not be disabled. Re-enabling an email address resets its bounce email heuristic score (described below). * We draw a red banner at the top of every web page rendered for this user. The banner informs them of the problem and links to the page with their registered email addresses, as described immediately above, so they can address the problem. * Starting a week later after entering the DISABLED PREFERRED EMAIL state, we send out an email once a week for up to four weeks to the preferred email address, telling the user of the problem and linking to the page with their registered email addresses, so they can address the problem. In this document, call this a PROBE email. * Launchpad (not Registry) administrators (https://launchpad.net/~admins) can change the disabled status of users' email addresses, and thereby affect the DISABLED PREFERRED EMAIL state. Background and heuristics, as strongly informed by Mailman [Arbitrary values in the below will be configurable, at a minimum by changing constants in a well-known place in the sourcecode. These arbitrary values are indicated with italics.] * Bounces can be classified as permanent or temporary. We effectively ignore temporary bounces. * Bounces can be caused by receiving bounce emails, or by getting SMTP errors when sending. Barry's flufl.bounce library is responsible for identifying and classifying bounce emails as permanent or temporary, as well as identifying the affected email addresses. For SMTP errors, the 450 code and 5xx codes can be regarded as permanent failures, and the other 400 codes can be regarded as temporary failures (see http://tools.ietf.org/html/rfc5321#section-4.2). * Each email address has a bounce score. An unknown/good email address begins with a score of zero. A score of *five* indicates that the address should be disabled. A permanent bounce (email or smtp error) causes an address' bounce score to increase by one. A given bounce score can only increase by one for any given *24 hour* period, so subsequent permanent bounces for the same address within that period are effectively ignored. * The bounce score for a given address is reset to zero if the address has not had a bounce for *seven days* and the address is above the "disabled" threshold. * Re-enabling an email address resets the bounce score to zero. === Nice to have === * If a user is in the DISABLED PREFERRED EMAIL state, this is visible to other Launchpad users, such as in bug subscription lists. * When a user views their email addresses, they see an indication if their preferred email address has had some recent bounce problems that have not yet led to disabling. * Let a user see the full text (including headers) of the most recent bounce from each of their emails. * Pay extra attention when a PROBE email: if it bounces, then it means...something in addition? See Mailman bug 808821. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
