[Mailman-Developers] Run_queue Process

Barry A. Warsaw bwarsaw@cnri.reston.va.us (Barry A. Warsaw)
Fri, 3 Dec 1999 00:44:32 -0500 (EST)

>>>>> "claw" ==   <claw@kanga.nu> writes:

    >> I would like to basically know how to delete the mail queue
    >> messages sometimes if I know there is going to be a lot of
    >> queued mail that I don't want delivered.

    claw> IIRC (can't check now) it is stored inside the config.db for
    claw> the list.  Removing that mail is a question of unpickling
    claw> the DB and removing the approriate records.

Actually, I don't think so.  I think those queued messages are just
gleaned from the file system.

    claw> <<An area that could stand some improvement FWLIW>>

And in fact, all this has changed in my current codebase.  There's no
queueing going on.  I have two delivery modules, one that pipes to the
command line interface of sendmail, the other which does direct smtp
delivery to the local smtpd.  This latter only handles error codes >=
500 (permanent errors), in which case it'll register a bounce to that
addr just as if a bounce message was received.

However, at least with Postfix, it appears that you never get error
reports for non-local addrs.  The dialog with the local smtpd seems
nearly asynchronous, which is actually a good thing.  If Postfix can't
deliver the message, it'll generate a bounce message for it (more on
this in another follow up).

I believe this all works differently if the MTA supports DSN (delivery
status notification), which sendmail does, but postfix does not.  In
that case, if you enable DSN, delivery becomes synchronous, and you do
end up getting error codes back for failures.  The problem with the
synchronous deliveries is that you can't keep list object locked while
that happens.

I'm beginning to think it's best not to do DSN and just improve the
bounce detection, or do the VERP-like approach discussed earlier.

I think Dragon has said that he's got a better bulk mailer
implementation that he's been using for a while.  I think he's talked
about porting it to the new delivery pipeline code, which would be
cool to have as an alternative approach.