MM3 not processing some mails from specific user
Hi,
we are running MM3¹ and from time to time, a mail to a mailing list is not processed by MM. MM sees the mail but still does nothing with it. If another user is sending _same_ mail, it is processed.
Any idea what that could be? Here are some logs:
Apr 27 13:02:13 2022 (1919) ('127.0.0.1', 44800) handling connection Apr 27 13:02:13 2022 (1919) ('127.0.0.1', 44800) Data: b'LHLO mal01.mydomain.tld' Apr 27 13:02:13 2022 (1919) ('127.0.0.1', 44800) Data: b'MAIL FROM:<john.doe@mydomain.tld>' Apr 27 13:02:13 2022 (1919) ('127.0.0.1', 44800) sender: john.doe@mydomain.tld Apr 27 13:02:13 2022 (1919) ('127.0.0.1', 44800) Data: b'RCPT TO:<ssa@mydomain.tld>' Apr 27 13:02:13 2022 (1919) ('127.0.0.1', 44800) recip: ssa@mydomain.tld Apr 27 13:02:13 2022 (1919) ('127.0.0.1', 44800) Data: b'DATA' Apr 27 13:02:13 2022 (1919) ('127.0.0.1', 44800) Data: b'QUIT' Apr 27 13:02:13 2022 (1919) ('127.0.0.1', 44800) connection lost
Here is a snipped from same user, but different mail that is also not processed by MM:
Subject: =?iso-8859-1?Q?Kleine_=C4nderung?= From: john.doe@mydomain.tld To: =?us-ascii?Q?ssa=40mydomain=2Etld?= <ssa@mydomain.tld> Date: Wed, 10 Aug 2022 12:33:36 +0000 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_m+9Z-w1zPVUy50id4xiOsxEs50Bl3xTDSq7AWqqonRf21H5c" Thread-Index: AdistWce8WLKbSqIReeBnR+y5yR5Mw== Message-Id: <kcEE.3C4Toxi/SomLpNH7qUNdhg.gBB2y7Ws2AE@mx1.mydomain.tld>
This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_m+9Z-w1zPVUy50id4xiOsxEs50Bl3xTDSq7AWqqonRf21H5c Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Das ist ein Test
--=_m+9Z-w1zPVUy50id4xiOsxEs50Bl3xTDSq7AWqqonRf21H5c--
Any help is greatly appreciated. Thank you.
¹ 3.1.1-9 (update is scheduled)
Stefan Bauer writes:
Any idea what that could be? Here are some logs:
I don't see anything in either the MTA log or the sample message. However the sample message is incomplete, I assume the rest is an HTML version of the plain text MIME part. It's unlikely but possible that there is a defect in the rest of the message.
Have you checked the Mailman logs? Typically they end up either in /var/log/mailman or /var/lib/mailman/log (or variations on those appropriate for your installation)
Also, check the shunt queue, typically in /var/lib/mailman/queue/shunt. This is where Mailman puts messages that contain errors that didn't prevent delivery but make processing impossible.
Steve
Hi Stephen,
thank you. Funny. All problematic mails are in the shunt-queue from one specific user. the mailman-logs did not log anything helpful.
What do you recommend to find the needle in the haystack? I mean, what can cause mailman to fail processing?
Stefan
Am Do., 11. Aug. 2022 um 14:30 Uhr schrieb Stephen J. Turnbull < stephenjturnbull@gmail.com>:
Stefan Bauer writes:
Any idea what that could be? Here are some logs:
I don't see anything in either the MTA log or the sample message. However the sample message is incomplete, I assume the rest is an HTML version of the plain text MIME part. It's unlikely but possible that there is a defect in the rest of the message.
Have you checked the Mailman logs? Typically they end up either in /var/log/mailman or /var/lib/mailman/log (or variations on those appropriate for your installation)
Also, check the shunt queue, typically in /var/lib/mailman/queue/shunt. This is where Mailman puts messages that contain errors that didn't prevent delivery but make processing impossible.
Steve
On 8/12/22 00:58, Stefan Bauer wrote:
Hi Stephen,
thank you. Funny. All problematic mails are in the shunt-queue from one specific user. the mailman-logs did not log anything helpful.
Mailman's var/log/mailman.log (or wherever it is) should have logged an
exception with traceback for each shunted message. What are these
tracebacks? Search the logs for SHUNTING (all upper case) to help find
them.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Stefan Bauer writes:
thank you. Funny. All problematic mails are in the shunt-queue from one specific user.
That's good news (given that things aren't working), something in there will show us why.
the mailman-logs did not log anything helpful.
I thought they should ... not your problem, I'll check and let you know if there's someplace else you should look.
What do you recommend to find the needle in the haystack? I mean, what can cause mailman to fail processing?
Most frequently the issue is a non-ASCII character in the header. A frequent cause is spam filters and virus checkers quoting non-ASCII text in their reports in the header. Nonconforming dates can cause problems for some applications (specifically those that work with list archives), but I don't think they should cause non-delivery, and the date in the sample message is conformant.
You could try running "mailman unshunt", which may produce a helpful error message if for some reason it can't do so. Also check for logs that were updated at that time, which might identify a log with some useful information.
Steve
On 8/12/22 11:26, Stephen J. Turnbull wrote:
You could try running "mailman unshunt", which may produce a helpful error message if for some reason it can't do so.
Unshunt won't issue an error. It will just move the message back to the original queue. Then, presumably, processing will throw the same exception which should be logged in mailman.log, and the message will be shunted again.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Mark Sapiro -
Stefan Bauer -
Stephen J. Turnbull