Do you struggle with message rejected. AUP#CDRBL while using mailman with your ISP email relay?
I'm impressed by Philip Bondi's use of mailman[23] for home financial automation. ("Take off Eh!") ... It seems like a ticketing system would be a better system for such a use... maybe the IETF SML WG will further help with this.. (I find most Canadian financial institutions are so far behind the curve)
I think that your email is hosted by hostedemail.com? I'm guessing that "eshop" is the mailbox you use for these common notices, and maybe you retrieve that into your mailman3 with fetchmail or something? Or does your ISP turn around and SMTP to you directly? Is it your MTA, their MTA, or mailman that is doing the rejection?
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.
On 4/18/25 9:37 AM, Michael Richardson wrote:
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.
It seems that maybe not all the runners are running. What's in Mailman's various var/queue/* directories? What's in Mailman's var/logs/mailman.log?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
participants (3)
-
Mark Sapiro -
Michael Richardson -
Stephen J. Turnbull