On 6/15/20 8:47 AM, rongxinliu@cs50.harvard.edu wrote:
We tried deleting this mailing list and recreating a new one, but no luck. We also tried restarting mailman, and the issue persists. When looking at the mailman.log, messages sent to this problematic mailing list are accepted and archived successfully without a noticeable issue.
In the smtp.log, also no errors are found except one line "Connection lost during _handle_client()", but this is true for all other mailing lists.
Yes, that's normal.
...
However, the mailing list having issue will just stop at: ....... Jun 15 14:04:29 2020 (23) Connection lost during _handle_client()
There are a couple of things. The post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... includes the log message:
Jun 09 17:36:31 2020 (82) Cannot connect to SMTP server postfix on port 25
This is strange as it says that Mailman is trying to connect to hostname
postfix. Is this actually a legitimate host name on the Mailman server
that Mailman can connect to? However, it doesn't seem that this is the
issue as that name comes from the smtp_host setting in the [mta] section
of the configuration and is global so if it were wrong, it would affect
all lists.
The fact that there is nothing after "Connection lost during _handle_client()" message means only that the message wasn't successfully delivered.
A database issue seems unlikely.
Set
[logging.smtp] level: debug
in mailman.cfg and see if the increased logging helps.
It seems to me that the most likely issue is a list member whose address in an smtp RCPT TO command causes some issue with the MTA.
Does the MTA actually see a connect and commands for the delivery attempt.
I'm also confused by
The out-runner keeps creating new .pck and .bak files endlessly whenever an email gets sent to this mailing list.
Mailman should create a .pck in the out queue. Then the out runner processes it and renames it as a .bak during processing for recovery purposes and when done processing removes the .bak. If in the process it encounters retryable errors for one or more recipients, it will remove the successful and perm failure recips from the metadata and queue the message in the retry queue. It should never be just requeueing the message in the out queue.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan