Hello everyone,
I just had a look into Mailman again. The API seems to be very clear, even
though I could not find any UML diagrams anywhere. However I found out that
porting Mailman to Zope (as a Python Product) might be a very simple task.
Due to the nature of the project, the implementation
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 pro
> 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 fre
Ok, I've thought more about this today, and optimized my code a little..
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 incre
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 o
> "CVR" == Chuq Von Rospach <[EMAIL PROTECTED]> writes:
CVR> If the bounce is RFC compliant, it's fairly simple to
CVR> determine "hard" and "soft" bounces, and since they are
CVR> following the standards, it's not a huge amount of
CVR> work. Treat a "soft" bounce as half a b
On 11/30/01 10:08 PM, "Dale Newfield" <[EMAIL PROTECTED]> wrote:
> 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
What you might consider is this:
