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

[Bob Puff@NLE]

Barry:

Good thoughts.  Let me add something:

On all my lists, if a person is bouncing, I want them removed, not just set to nomail.  Otherwise as you mentioned, the nomail list gets bigger and bigger.  AFAIK, the only people that should be on the nomail list are those who have signed up as such.

So if you want to do the "I'm about to nuke you, one last chance" thing, I would suggest _another_ bit be used in their settings to identify this.

Also update list_members so that you can sort by these fields.  (Shameless plug - my modified list_members already lets you sort by nomail, and digest type.  Did this patch get merged into 2.08?)

I'm not so sure if doing an estimated average of messages sent is the right thing.  How about something like this:

Each user has three entries: time/date stamp for first bounce, time/date stamp for last bounce, and a bounce counter (16 bits should be fine!)

Upon a bounce, do this:

1. Time/date stamp the last_bounce field with the current time/date.
2. Check the first_bounce field to see if it is null.  If so, put the current time/date stamp there too, and set the bounce_counter to 0.
3. Increment the bounce counter.  (actually not used in this text.)

Do nothing else at this point.

Now, we know when a regular message goes out, and we also know when a digest goes out.  Keep a record of the last x (21?) days' worth of postings (see below).

Now! Once a day, set up a cron script to go through each user entry.  Do the following:

1. Examine the first_bounce time/date stamp.  If null, skip to the next user.
2. Check out post log to see how many days since first_bounce have had messages.  Is it less than X days?  
   YES: does last_bounce = the last entry date in the posting log (or today)?
        YES: we're still bouncing, but haven't hit our cutoff yet.  Skip to the next user.
        NO: NULL out the first_bounce, and go to the next user.  We apparently stopped bouncing, so we need to reset.
   NO: we've hit our age limit.  Let's see if he's still bouncing:  Does last_bounce = the last entry date in the posting log (or today)?
        YES: NUKE EM!!!
        NO: Null out the first_bounce, and go to the next user.  Apparently this guy really lucked out, and stopped bouncing the day before he would have been nuked (remember, we are doing this every day).

The posting log would only need to have a single entry of a date for each day that a message was sent thru the list, i.e.,
11/28/01
11/29/01
11/30/01  etc...

This could be updated at the same time the daily_digest is dispatched, or it could be part of the main qrunner system.  The key is having an entry here for each day a message is sent out.  It is such a small file that you could suck it into memory, and "rotate" it so that it only keeps a history of x+1 entries (say 21).

This allows us to catch and properly detect the bounces for the inactive lists as well.

Notice that I didn't even use the bounce_counter.   You could still test for it, but I think continuous bouncing over x days is a better method to use.

Using the above algorithm does have this flaw: if a user bounces one message per day, it will still remove them.  But sporatic problems usually don't surface like that.

Bob