[Mailman-Users] Bounce Options

Dan Wilder dan at ssc.com
Thu Nov 29 19:08:24 CET 2001

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 number of days an address has been non-fatally
  bad before we take action


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


  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.

 Dan Wilder <dan at ssc.com>   Technical Manager & Editor
 SSC, Inc. P.O. Box 55549   Phone:  206-782-8808
 Seattle, WA  98155-0549    URL http://embedded.linuxjournal.com/

More information about the Mailman-Users mailing list