[Mailman-Users] Lists stop working

[Rolf E. Sonneveld]

Hello, Mark,

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 
subscriber).

>   
>> 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
> OutgoingRunner.
>   

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.
>
>   

/rolf