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

[Barry A. Warsaw]

>>>>> "B" == Bob  <bob@nleaudio.com> writes:

    B> On all my lists, if a person is bouncing, I want them removed,
    B> not just set to nomail.

I envision this as possible via the 1st phase disposition being set to
"Remove now" (with or without one last notice).
    
    B> Otherwise as you mentioned, the nomail list gets bigger and
    B> bigger.  AFAIK, the only people that should be on the nomail
    B> list are those who have signed up as such.

Yes, I want to separate the concepts of disabled-by-choice and
disabled-by-bounce.  Right now, you've got no idea.

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

It will likely be implemented as a separate flag, mostly for backwards
compatibility.  Actually, it's possible that both disabled-by-* states
will be represented by new flags so we can try to do /something/ with
the current messy state of affairs.

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

Nope, but it wouldn't anyway.  I've consigned 2.0.x to critical
(mostly security) fixes only.  Otherwise, there's no hope 2.1 will get
done. ;)

    B> I'm not so sure if doing an estimated average of messages sent
    B> is the right thing.

Me neither.  It /seems/ reasonable...
    
    B> How about something like this:

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

    B> Upon a bounce, do this:

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

    B> Do nothing else at this point.

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

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

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

If I understand your approach correctly, the problem is that bounces
may be clumped and may not be correlated in time with the postings
that causes them.  You might send out 10 messages today, but you may
not see the bounces for them for a couple of days.  And then you might
see all 10, one today and nine tomorrow, etc.  And there's no feasible
way to connect the bounces with the messages they were in reference
to.  By averaging things out, I'm trying to get a general sense of
whether the user is receiving things or not.

The interesting idea you have is the post counter buckets.  By keeping
a sliding average of only the last 30 days or 60 days our bouncer
might adjust better to longer term changes in mailing traffic, while
still smoothing out the peaks and valleys.

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

I'm more concerned with the user who fills up his disk and doesn't
notice it for a week because they're on vacation.  I'd like Mailman to
be robust against this, and I think the average non-deliveries over a
couple of weeks, with consignment to probation probably catches most
of this use case.

Thanks,
-Barry