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

[Chuq Von Rospach]

On 11/30/01 11:18 PM, "Barry A. Warsaw" <barry@zope.com> wrote:

>   B> I'm not so sure if doing an estimated average of messages sent
>   B> is the right thing.
> 
> Me neither.  It /seems/ reasonable...

It is, but it's lots of work.

How about something simpler:

Timestamp the FIRST bounce on each day. Then, track bounces for N days (N
being configurable per list). If you're allowing a user to bounce for 3
days, then if you have a bounce for day N, and day N-3, then you have a
match and the user is disabled. At some time longer than N days, bounce
timestamps are deleted, since they're no longer valid.

You can set a default value for the 'typical' list as the default. I tend to
think that any moderately busy list (say, more than 2-3 messages a day)
would be handle by N=3 to N=5, depending on whether you want to avoid the
possibility of long-weekend-daemon breakage or not.

Then add in the "soft bounce = .5 bounce", and soft bounces would extend N.
And digests, do they need to be handled differently? I tend to think so. For
digests, to be careful, I'd probably start them at soft-bounce, and if their
bounces ARE soft, go to .25 bounce...

Trying to count messages and then figure out some percentage of them as
having bounced, and etc -- I think from my experience it's overkill. You get
almost all of that by keeping track of "we have records of bouncing over
this period of time....". You might occasionally nail a person who's system
is bouncing every 8th message or some godawful thing, but IMHO, that person
ought to thank you for helping them find that out...

For announce, moderated and or things like e-newsletters, with very low
volumes, an admin would have to decide what N should be, and likely, set it
longer. You might want to keep track of them for 14 days, and if you've
bounced at least twice in that time (once 14 days ago, once today), that
constitutes a legitimate bounce. For something like an e-newsletter, N might
even be 45 or 60 days: imagine a once-a-month beast where you want at least
two bounces to prove it's dead.

Hmm. That brings up a glitch in my design. If you have < 1 posting a day,
that first posting has to be within some "window" around that N days, you
can't depend on it being exactly N days away. So you really need some kind
of way of saying "Bounces N days apart, with at least M bounces in that
time, and the first bounce within Q days" -- 60 days, 3 or more recorded
bounces, first bounce within 5 days of "N". Make sense?

It's still a much simpler accounting system than we currently have, or one
that requires tracking what the list does, and trying to guess what bounces
should do from that. Let the admin define the policy, which boils down to
"how long", "minimum # of bounces in then" and "granularity" (for lack of a
better word)

> If I understand your approach correctly, the problem is that bounces
> may be clumped and may not be correlated in time with the postings
> that causes them.

This is correct. There are some sites (not as prevalant as it once was) that
only send back bounces and admin mail during "off" hours. Since most of them
seemed to be european, of course, it meant their bounces showed up in MY
prime time, but that's not their problem.... (grin). You can't depend on
bounces returning in any kind of "reliable" stream.

> I'm more concerned with the user who fills up his disk and doesn't
> notice it for a week because they're on vacation.  I'd like Mailman to
> be robust against this, and I think the average non-deliveries over a
> couple of weeks, with consignment to probation probably catches most
> of this use case.

The above handles that, especially if you throw in the "soft bounce"
factoring... You can set "N" to a week, or ten days, if you don't mind
having more bounces flowing in and out of the system. But users who need to
minimize throughput or are more willing to be strict can cut it shorter.

(one other thought, which some mailers do. When bounces START, switch them
to digest mode. It cuts the overhead on all sides, and allows them a cahnce
to fix things before disabling, without all those bounces and etc rolling
around... )