[Mailman-Developers] Here's a little issue with the news gatewaying: If the n

[Barry A. Warsaw]

>>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

    JRA> I shouldn't think so... and it's not like this list has been
    JRA> swamped with traffic... I *still* haven't gotten an answer to
    JRA> *my* first question, asked last Friday... :-}

Right at the tail end of IPC9, so that's not too surprising.  Do you
mean

    JRA> The doco says the site password will work anywhere... but it
    JRA> doesn't seem to work as the "old password" for changing a
    JRA> list password, and I can't find anywhere *else* to do that
    JRA> either.  Am I missing something, or is that really a bug?
    JRA> I'm gonna check Jitterbug for that, too, during my search.

I definitely can't reproduce this in 2.0.3 or 2.1.  Works for me.  Are
you sure you've got the crypt module installed in your Python
executable?

Or was it

    [w.r.t. max chunks per day hack]
    JRA> Will this approach cause locking problems, etc?

It worries me because you're basically freezing all mail delivery on
all lists for some fraction of an entire day.  So while people will
still be able to hit the cgi for this list (since the list is
unlocked), no mail will flow through the system at all while you're in
that sleep().  Note that while SMTPDirect for the actual mail delivery
task can be configured to run multiple threads, qrunner itself is
single threaded, and the message pipeline will block at SMTPDirect
until it's done with its work.

Your qrunner lock could be broken during that time.  Qrunner's lock by
default is 10 hours, so say you only deliver one chunk per day.  10
hours from now cron will start another qrunner, the lock will get
broken, and now you've got two qrunners stomping on each others toes.
Badness.

[Aside: your bare "except:" isn't good Pythonic form.  You should
adorn that except with the most specific exception you expect to
get.  In this case AttributeError.  Bare excepts should be reserved
for the (very) rare case of framework wrappers, a la scripts/driver.]

A slightly different approach to take would be, if you exceed your max
chunks per day threshold, break out of the deliver() function, setting
the refused dictionary to contain all the recipients in chunks that
are deferred.  Set the error code to something in the 400 range (to
indicate a temporary failure), and this will cause a
SomeRecipientsFailed exception to be signaled to the delivery
pipeline.

Then you should add a timestamp to the msgdata for when you processed
this chunk and at the top of SMTPDirect.process(), simply return if
the timestamp is less than your delay period.

Without testing it, that approach (or something like it) ought to work
better.

I'd also suggest adding this as a feature request to the SourceForge
feature request tracker, so it doesn't get lost.

Cheers,
-Barry