[Mailman-Developers] bounce processing in 2.1CVS

Barry A. Warsaw barry@zope.com
Tue, 29 Jan 2002 13:42:12 -0500


>>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes:

    DM> I could be high, but it looks like the sequence in Bouncer.py
    DM> is:

    | 1) are we a member?  No, return
    | 2) do we have previous bounces?  No, register it and quit
    | 3) is the member disabled?  yes, quit
    | 4) is the bounce info from today?  yes, quit
    | 5) is the info stale?  yes, clear it out
    | 6) start looking for action

    DM> It seems like 4) is pretty procrustean.  If, for instance, I
    DM> have a wad of bounces, and decide "screw it, if they get to
    DM> one bounce, I want them gone" and change the bounce threshold,
    DM> that's not going to take effect until tomorrow.

You have a good point.  I think this is best handled by a slight reorg
of registerBounce(), so that the check of the bounce score is always
done after adjustment of the bounce score.  I.e.

1) are we a member?  No, return
2) do we have previous bounces?  No, register it skip to step 7
3) is the member disabled?  yes, quit
4) is the bounce info from today?  yes, don't increment, skip to step 7
5) is the info stale?  yes, reset it and skip to step 7
6) increment score for today's bounce
7) is score > threshold?  yes, disable 'em.

    DM> And besides, that seems like a useful knob to turn (i.e. "how
    DM> old does the bounce info have to be before I start looking for
    DM> new ones").

It might be, but I think for now I don't want to add that.

I realized you also want to add a step in cron/disabled that performs
a sweep over the currently-bouncing-but-not-yet-disabled members,
checking their scores against the threshold.  Say this morning the
threshold was 4.0 and some member had a score of 3.0.  Then I go in
and say screw it, set the threshold to 2.0.  I'd like today's
cron/disabled run to disable all those members with a score of 3.0.

Checking in this stuff to cvs momentarily.

Thanks,
-Barry