[Mailman-Developers] Re: Bounce removal parameters default values

[Barry Warsaw]

On Fri, 2003-09-26 at 12:24, Simone Piunno wrote:
> On Friday 26 September 2003 17:47, Barry Warsaw wrote:
> 
> > Admins of low volume lists might want to change some of the bounce
> > processing defaults.  However, by default if a list gets no bounces from
> > you in 7 days, it considers any previous bounce info to be stale and
> > throws it away.  So the list would need to get one bounce per day from
> > you for 5 days in a row for you to get disabled.
> 
> You write it as it was extremely difficult... but in reality on the server I 
> manage it happened a dozen times in the last month (4 times to me alone).
> This is getting pretty annoying.  I get disabled on 20-30 lists, spread on 
> different virtual domains, so even the "globally" option in the re-enabling 
> form doesn't help much (cause globally = virtual-domain-wide).
> I don't have any solution but please don't dismiss this problem.

I won't, and I'm definitely interested in specific suggestions, but of
course there are other contributing factors to the problem.  Are there
better defaults we could be shipping Mailman with that would make the
problem less severe without making automatic bounce processing useless?

> > The other option I would suggest is that list owners start turning on
> > personalization, in order to take advantage of VERP.  I think it's
> > harder to get spoof-disabled when VERP is enabled because then Mailman
> > looks for the bouncing address in the encoded recipient header.
> 
> This looks promising.  Is there any howto explaining how to migrate to VERP on 
> a running list and what gotchas to pay attention?

Part of setting up VERP is MTA specific, and there are instructions in
README.POSTFIX and README.EXIM covering those MTAs.  Once that's done,
its a matter of setting the various VERP_* variables in mm_cfg.py to
your tastes, and then turning on personalization (not full) in
Non-Digest deliveries.

The bigger question is what the impact of VERPing is on bandwidth and
performance.  Other than doing the math, I don't have much to add,
except that I've started to enable it on most python.org lists and it
doesn't seem to be a problem.

-Barry