[Mailman-Developers] Re: [Mailman-Users] Bounce Options

[Barry A. Warsaw]

Here are some of my recent "shower" thoughts about bounce handling
(i.e. what does Mailman do /after/ it detects a bounce?).

- We can't do any positive delivery death-resets because in general
  we're never informed about successful deliveries.  Anything that
  relies on such notices will be too unreliable.

- We (can) know exactly two things:
    1) how many messages we've sent per period of time
    2) how many bounces we've in that same period of time from a
       specific user

- It's probably infeasible to link specific deliveries with specific
  bounces (we could possibly do it w/VERP, but it'll make things too
  complicated).

- For simplicity, let's treat non-fatal bounces (some temporary
  outage) the same as fatal bounces (user goes away)

- We want to keep the knobs that a list admin can twiddle to a
  minimum, and make them completely obvious.

- Provide a multi-phase disposition to bouncing addresses.  I.e. at
  the first phase we disable them, then we send some disable
  notifications, then we remove them.

- We need to differentiate b/w disabled-by-bounce and
  disabled-by-choice.

So, here's my proposal:

Each list has a "bounce start date", which can be the list's creation
date if it has one (MM2.1), or some arbitrary time post where we start
counting.

We already count the number of messages sent through the list via the
post-id.  We may need to reset this to zero if we're using an
arbitrary t0.

These two pieces of information give us the number of messages/day
average being sent though the list.

When a user starts bouncing, we record the start time.  We continue to
count the number of bounces from this address for some configurable
amount of time.

    List admin knob 1: For how many consecutive days should an address
    be bouncing before we take action?   Proposed default: 14

After that, we look at how many bounces this person had, and the
average delivery rate of the list.  We can thus calculate roughly the
percentage of deliveries that this user bounced.

    List admin knob 2: Percentage of total deliveries to the list that
    must bounce for an address, in the above time period, for that
    address to be automatically disposed of.  Proposed default: 50%

Thus if we sent out an average of 500 messages to the list, and over
the last 14 days we saw 250 bounces from bogus@dom.ain, we would
dispose of this address.  (Side note: we have to keep track of regular
vs. digest deliveries separately).

    List admin knob 3: Action to take when disposing of a bouncing
    address.  "Disable w/ occasional reminders", "Disable w/ one last
    notice", "Disable w/o notice", "Remove now w/ one last notice",
    "Remove now w/o notice".  Proposed default: "Disable w/ occasional
    reminders".

All but the first should be obvious.  "Disable w/ occasional
reminders" means we disable the address from regular delivery, but
start sending them occasional reminders about their disabled
delivery.  The reminder will contain instructions for re-enabling, as
well as a note like "You will receive 3 more reminders over the next
21 days unless you take action".

    List admin knob 4: How many days should there be between reminders
    to disabled addresses?  Proposed default: 7

    List admin knob 5: Total number of reminders to send before second
    order disposition occurs?  Proposed default: 4

A person who's membership has been disabled due to bounces must
explicitly re-enable delivery via their options page, or via the
confirmation cookie contained in the reminder messages.

    List admin knob 6: Second order disposition for bouncing members
    who do not re-enable their accounts: "Disable w/ one last notice",
    "Disable w/o notice", "Remove now w/ one last notice", "Remove now
    w/o notice".  Proposed default: Remove now w/ one last notice.

The last knob allows the list administrator to cull all disabled
bouncing addresses in one fell swoop.  This will be a volatile option
that performs an immediate action.  Note that only addresses disabled
via bouncing will be removed.

If a member has been bouncing because of temporary problems, they
will probably never reach the threshold for automatic phase 1
disposition, given a high enough percentage or a long enough tracking
period.  Even if they are, and we send out reminders, they should be
able to just go to their options page and re-enable (the options page
clearly tells them that their account is disabled).

Mailman has a problem currently that we have no idea whether an
address is disabled-by-choice or disabled-by-bounce.  We need to fix
that, but what to do about all the addresses that are currently
disabled?  We could just treat them all as disabled-by-bounce, sending
an occasional reminder, and asking them if they really want to keep
their disabled membership, they should go to their options page and
re-click on the no-mail option.  Anybody who doesn't do this within
the second-phase gets removed as per above.

Thoughts?
-Barry