On Thu, Nov 29, 2001 at 10:35:21AM -0500, Clark Cooper wrote:

I am running Mailman 2.0.8 and am wondering how the Bounce Options in the Admin menus work. Basically, I would like to automatically disable an account for X number of bounces. My testing does not show any such actions taken for X bounces for an invalid list member email address. I have the default settings for all options. Can some explain how this works?

Thank you, Clark Cooper

I'll chime in on that one too.

I've tried, though probably not hard enough, to read the code to figure out how bounces are handled. I see parameters for

minimum_removal_date

Minimum number of days an address has been non-fatally bad before we take action

minimum_post_count_before_bounce_action

Minimum number of posts to the list since members first bounce before we consider removing them from the list

max_posts_between_bounces

Maximum number of messages your list gets in an hour

That last one has a name that's somewhat at variance with its help description; and the code itself, as near as I follow it, appears to do something a little bit different from either the name or the description. The only place it is referenced is in Bouncer.py:

if self.post_id - hist[2] > self.max_posts_between_bounces: ... syslog("bounce", report + "first fresh")

which appears to (??) forgive but not forget.

It isn't obvious what to do with this one for low-traffic lists, such as several announce lists I run, which receive exactly one post a week. The ideal behavior for an announce list would be to remove members after a configurable number of consecutive (not cumulative) bounces, regardless of any other consideration.

Clearly that is difficult to achieve in this context, as this code activates only on delivery failure, not on delivery success, which is difficult to gauge; so there's some sort of proxy information needed, and perhaps that proxy information could be calculated from estimates of posting rate and bounce thresholds; that appears to be what's attempted here.

Setting this to a large number seems to work better for a low-traffic list than setting it to a small number. That's somewhat counterintuitive, at least based on the descriptions of the value.

I guess I'm wondering if anybody recalls the intent of this code.