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

[Dan Wilder]

On Fri, Nov 30, 2001 at 11:06:36AM +0000, Nigel Metheringham wrote:
> On Thu, 2001-11-29 at 23:55, Dan Wilder wrote:
> > So what's a reasonable intent for bounce handling?  
> > 
> > Here's a sketch.  No doubt I misunderstand important points.
> > Perhaps others would be kind enough to comment.
> > 
> > Presuming the list is configured for automatic bounce handling
> > at all, it would seem reasonable to claim that there are 
> > circumstances under which bounce handling might unsubscribe or 
> > disable mail to a subscriber.
> 
> Definitely.  In general I (as list admin) want almost zero involvement
> here.
> 
> > The sporadic bounce probably shouldn't cause this sort of action.
> > So, there should be some forgiveness mechanism in place.
> 
> Yes - I occaisionally bounce stuff from bugtraq because we have a filter
> on that bounces executable content (ie outlook virus hacks), but it also
> bounces some exploit code :-)
> So I sometimes bounce 10% of the messages in a day.
> 
> > Several bounces over a short period of time might reasonably
> > be forgiven, or treated as a single bounce.  Many situations
> > that will cause a bounce involve some misconfiguration which
> > the conscientious sysadmin will shamefacedly correct as soon as
> > it is brought to his or her attention.  A heavily trafficked
> > list might not want to unsubscribe even members who cause several
> > bounces, providing these fall within a short period of time.
> > 
> > Several bounces over a longer period of time might be cause
> > for suspension, even if posts are accepted between.
> > 
> > The existing bounce handling makes some distinction I don't
> > understand between "fatal" bounces and "nonfatal" bounces.  
> > Is this "no such user" versus "host busy", for example?
> 
> SMTP has immediate and retryable errors
> 
> For an announce list - I have a few (similar to mailman-announce) which
> have traffic in single digits per month (if that high), the rules may
> need to be different - 2 bounces from a user in 5 days is going to be
> close to impossible to achieve for example :-)

On the other hand, removal after four bounces within two months might work 
OK for you.  Provided there's some way to forgive those who also
accepted delivery on, say, three consecutive posts.

> Unfortunately its hard to identify correctly delivered messages - so you
> cannot easily use a "if a message is delivered correctly, reset the
> death counter" approach - 

Yes.  That could be what's behind some of the difficult-to-understand
and maybe broken stuff in Bouncer.py.

No news would seem to be good news.  Provided there's been a post or 
two during the "no-news" time.  

An adequate forgiveness mechanism should probably take list
traffic into account, but I'll confess I'm having a hard time
getting my head around just what would make sense.  Everything
I think of gets complex too fast.  A sign of either an intractable 
problem or a wrong solution.  I can't believe this problem is
intractable.

> one UK ISP routinely bounces mail to their
> users that has not been picked up after 30 days (and their bounce
> messages are currently unparsable).

Ugh!

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