[Mailman-Users] Lists stop working
Rolf E. Sonneveld
R.E.Sonneveld at sonnection.nl
Fri Apr 27 23:54:50 CEST 2007
Mark Sapiro wrote:
> Stephen J. Turnbull wrote:
>> Fairly early in message processing, Mailman logs to either logs/post
>> (showing that the post was accepted) or to logs/vette (indicating that
>> the post was held or rejected, and why).
> One minor point here. The post log entry is not written until the
> message is delivered by SMTPDirect.
OK, thus only after the message has been delivered to at least one
subscriber (or the first MTA in the chain of delivery to at least one
>> When the post is delivered,
>> there will be an entry in logs/smtp for each batch of deliveries
>> (usually one per remote host, or one per user if personalization or
>> VERP is being used).
> Actually, if nothing goes wrong, there will be only one entry in the
> smtp log covering all deliveries. If things go wrong there will be
> perhaps multiple entries in both smtp and smtp-failure logs.
In my case there were no entries in smtp nor in smtp-failure.
> In spite of the minor corrections above, Stephen's advice is excellent.
> To elaborate on Rolf's question about how Mailman processes a post.
Thanks _very much_ for the detailed explanation of the inner working of
Mailman. I really appreciate your detailed description!
> Assuming a standard configuration where the MTA delivers to the
> mail/mailman wrapper.
> 1) The MTA pipes the message to the wrapper which passes it to the
> scripts/post script which in turn places it in the qfiles/in queue.
> Nothing is logged in Mailman, but the MTA normally logs the delivery.
Now here's the problem, I think. The MTA logs the message as being
delivered to Mailman (via the wrapper script
$MAILMANDIR/mailman/bin/mailman), so from the MTA's point of view it's
done. Now, as the sent message cannot be found under qfiles, and as none
of the $MAILMANDIR/logs/* files is modified, it seems as if the message
disappeared in a black hole. Is there no way to enable debugging in the
wrapper script? It would show the first action of Mailman, I assume.
> 2) IncomingRunner picks up the queue entry from qfiles/in and passes it
> through a pipeline of handlers (GLOBAL_PIPELINE - defined in
> Defaults.py, possibly modified in mm_cfg.py - unless the list defines
> a pipeline attribute to override it). The initial handlers check
> header_filter_rules, look for an Approved: header and possibly
> generate an autoresponse. The next set of handlers checks for
> moderation and other holds and does content filtering, emergency
> moderation and topic flagging. Any of these handlers can raise
> exceptions to request IncomingRunner to discard, reject or hold the
> message at that point. Discards and holds are logged in the vette log.
> Rejects are not logged, but result in a reject message to the poster.
> Any other exceptions cause the message to be moved to qfiles/shunt and
> the exception is logged in the error log.
> The next set of handlers determines the recipient addresses and
> possibly removes and/or modifies some message headers.
> Then handlers add the message to lists/<listname>/digest.mbox if the
> list is digestable (and possibly trigger a digest on size), add the
> message to qfiles/archive for processing by ArchRunner, possibly add
> the message to qfiles/news for processing by NewsRunner, update the
> list's last_post_time, send an acknowledgement to the poster if
> requested, and add the message to qfiles/out for processing by
FYI I made sure that the recipients where no digest users.
> 3) ArchRunner picks up the queue entry from qfiles/archive and adds it
> the the list's archive.
> 4)NewsRunner picks up the queue entry from qfiles/news and delivers it
> to Usenet.
> 5)OutgoingRunner picks up the queue entry from qfiles/out and calls
> SMTPDirect to deliver it to the outgoing MTA via SMTP. SMTPDirect logs
> posts to the post log and logs a bit more detail to the smtp log. Any
> SMTP failures are logged to the smtp-failure log and treated as
> bounces or queued for retry as appropriate.
> 6) Any unanticipated exceptions in any of the runners cause the message
> to be moved to qfiles/shunt and the exception to be logged in the
> error log.
More information about the Mailman-Users