"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.
are we a member? No, return
do we have previous bounces? No, register it skip to step 7
is the member disabled? yes, quit
is the bounce info from today? yes, don't increment, skip to step 7
is the info stale? yes, reset it and skip to step 7
increment score for today's bounce
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