Michael Richardson writes:
My problem, on lists.sandelman.ca aka lists.tcpdump.org, is messages that appear to have been processed by my MTA (according to postfix logs), but which are never delivered, nor held. Lost somewhere in mailman3 queue. Sometimes they show up after a host reboot.
The queues are implemented the same way mail queues have been implemented since the Neolithic Era: save a file to disk, report success to the previous hop, then try to send its content to the next hop. If that succeeds, delete the file. If it does not, either send back a failure notice and delete the file, or hold the file for a later retry, depending on why it failed.
The queues are in $var_dir/queue/*. If you don't find the messages there, they were delivered successfully as far as Mailman could determine (ie, the outgoing smtp process reported a 2xx status). You can use the "mailman qfile" command to examine the contents of queue files. The shunt and bad queues are "sinks" -- if a message gets into those queues, Mailman will not try to deliver them because they caused some kind of error. The "mailman unshunt" (no argument needed) will try to resend messages in the shunt queue. Depending on why they got there in the first place, and whether that problem was resolved, they may be successfully sent, or they may end up back in the shunt queue. I forget how messages get into the bad queue, but there's no automated way to handle them at all.
Check the mailman.log and smtp.log logs (in $log_dir, by default $var_dir/logs) for reports on what mailman was up to. mailman.log is pretty verbose and interesting information is relatively sparse.
-- GNU Mailman consultant (installation, migration, customization) Sirus Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan