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 [EMAIL PROTECTED], 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 _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers