On 11/30/01 11:18 PM, Barry A. Warsaw [EMAIL PROTECTED] 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
Ok, I've thought more about this today, and optimized my code a little.. g
Check this out:
min_bounce_days = 5 (max # of days we say it will take for a bounce to come to us)
max_bounce_days = 14 (number of days to allow bouncing)
Once every day (really doesn't matter when), post_counter is
My simplification assumes that temporary failures really /are/
temporary! I think my approach is robust in the face of probably the
most common temporary failure I see as a list admin: a user running
out of disk space for a period of several days or a week. Once they
get a clue and free up
At 2:18 -0500 12/1/01, Barry A. Warsaw wrote:
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
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
Here are some of my recent shower thoughts about bounce handling
(i.e. what does Mailman do /after/ it detects a bounce?).
- We can't do any positive delivery death-resets because in general
we're never informed about successful deliveries. Anything that
relies on such notices will be too
Barry:
Good thoughts. Let me add something:
On all my lists, if a person is bouncing, I want them removed, not just set to nomail.
Otherwise as you mentioned, the nomail list gets bigger and bigger. AFAIK, the only
people that should be on the nomail list are those who have signed up as
On Fri, 30 Nov 2001, Barry A. Warsaw wrote:
- For simplicity, let's treat non-fatal bounces (some temporary
outage) the same as fatal bounces (user goes away)
Your scheme makes sense--I like the idea that subscribers can wind up on
probation (assuming the list admin configures the list that
B == Bob [EMAIL PROTECTED] writes:
B On all my lists, if a person is bouncing, I want them removed,
B not just set to nomail.
I envision this as possible via the 1st phase disposition being set to
Remove now (with or without one last notice).
B Otherwise as you mentioned,
DN == Dale Newfield [EMAIL PROTECTED] writes:
DN Your scheme makes sense--I like the idea that subscribers can
DN wind up on probation (assuming the list admin configures the
DN list that way). I understand that this simplifying assumption
DN makes the design much easier to
I've looked at this stuff too, and there are a number of things that
seem just plain broken to me. I'd like to rewrite it all, but I'm not
sure there will be time before 2.1.
I poked around in this myself a bit ago, w/o much benefit. It's a bit
jumbled in there, and I thought it was an
On Thu, Nov 29, 2001 at 04:04:23PM -0500, Barry A. Warsaw wrote:
[Changing followups to mailman-developers as this discussion really
belongs there. -BAW]
DW == Dan Wilder [EMAIL PROTECTED] writes:
DW I guess I'm wondering if anybody recalls the intent of this
DW code.
The
Yeah, I was just chatting with Barry about this. There are some serious problems with
the bounce handling. A user can be removed with only two bounces, if they occur 5
days apart (if you have your bounce handlign set to 5 days of continuous bouncing).
I have done some work in fixing up
13 matches
Mail list logo
