Hi Team,
I am currently running Mailman 3 with version 3.3.1 and in builtpostfix version 2.10.1-6 on RHEL 7.5 in production environment from the past 2 months almost.
Recently I observed a peculiar case. There is a list saytestlist@lists.testdom.com has a non member say testuser@testdom.com whose Moderation attribute is set to "Accept immediately (bypass all other rules).
This testuser@testdom.com has sent a mail to testlist@lists.testdom.comand postfix of my Maliman 3 received the request and handed over to Mailman at 0.0.0.0:8024 socket running on the same machine and the same is logged in /var/log/maillog.
Since the user has the moderation attribute set to Accept, the /var/lib/mailman/mailman/var/logs/vette.log also displayed "ACCEPT" on searching with the same message id.
At this point, to my expectations, there should be 2 entries for this message id in smtp.log one for smtp and one for post. But I don't find any log records with this message id in smtp.log and of course the mail is not delivered even.
Could you please help me out if I have missed any point or improperly understood the mail flow while using the mailman 3?
Please also let me know if I need to see any more log files for tracing the issue.
-- Thanks & Regards, Shashi Kanth.K 9052671936
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On 7/6/20 11:07 PM, Shashikanth Komandoor wrote:
Recently I observed a peculiar case. There is a list saytestlist@lists.testdom.com has a non member say testuser@testdom.com whose Moderation attribute is set to "Accept immediately (bypass all other rules).
This testuser@testdom.com has sent a mail to testlist@lists.testdom.comand postfix of my Maliman 3 received the request and handed over to Mailman at 0.0.0.0:8024 socket running on the same machine and the same is logged in /var/log/maillog.
So it was received by Postfix and delivered to Mailman.
Since the user has the moderation attribute set to Accept, the /var/lib/mailman/mailman/var/logs/vette.log also displayed "ACCEPT" on searching with the same message id.
And the post was accepted. (Apparently you override the path for logging.vette in your mailman.cfg since the default logs these to mailman.log)
At this point, to my expectations, there should be 2 entries for this message id in smtp.log one for smtp and one for post. But I don't find any log records with this message id in smtp.log and of course the mail is not delivered even.
You don't find the message-id in the smtp.log for the incoming LMTP because the message-id is not logged in this entry. It only logs the actual LMTP commands and the envelope sender and recipient(s).
You don't find the
<messageid> post to testlist@lists.testdom.com ... and <message-id> smtp to testlist@lists.testdom.com for nn recips, ...
entries because the post never got to that point in the processing (those are logged when the post is delivered to the list members).
Could you please help me out if I have missed any point or improperly understood the mail flow while using the mailman 3?
There was probably some exception in processing causing the message to be shunted. If so, the message is in the shunt queue and there is an entry in mailman.log for the exception and shunting with a traceback from the exception which will help in diagnosing the reason.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thank you Mark for your help.
Unfortunately, I felt myself dummy after seeing the mailman.log and the shunt queue. I did not find any clue from them.
I did not see any log records based on that message id in mailman.log. There is a lot much of shunt queue but I don't see any file with the required message id. The same is the bad queue also.
I find below two lines at that particular time stamp by when the log recorded in vette.log
*Uncaught runner exception: sequence item 0: expected str instance, Header foundTypeError: sequence item 0: expected str instance, Header found*
But I am not sure if the above lines are related to that missing message or not.
I am using postgresql as database. FYI, if it brings an idea to you to help me.
Could you please help me out how to trace further ?
On Tue, Jul 7, 2020 at 9:12 PM Mark Sapiro mark@msapiro.net wrote:
On 7/6/20 11:07 PM, Shashikanth Komandoor wrote:
Recently I observed a peculiar case. There is a list saytestlist@lists.testdom.com has a non member say testuser@testdom.com
whose
Moderation attribute is set to "Accept immediately (bypass all other rules).
This testuser@testdom.com has sent a mail totestlist@lists.testdom.com and postfix of my Maliman 3 received the request and handed over to Mailman at 0.0.0.0:8024 socket running on the same machine and the same is logged in /var/log/maillog.
So it was received by Postfix and delivered to Mailman.
Since the user has the moderation attribute set to Accept, the /var/lib/mailman/mailman/var/logs/vette.log also displayed "ACCEPT" on searching with the same message id.
And the post was accepted. (Apparently you override the path for logging.vette in your mailman.cfg since the default logs these to mailman.log)
At this point, to my expectations, there should be 2 entries for this message id in smtp.log one for smtp and one for post. But I don't find any log records with this message id in smtp.log and of course the mail is not delivered even.
You don't find the message-id in the smtp.log for the incoming LMTP because the message-id is not logged in this entry. It only logs the actual LMTP commands and the envelope sender and recipient(s).
You don't find the
<messageid> post to testlist@lists.testdom.com ... and <message-id> smtp to testlist@lists.testdom.com for nn recips, ...
entries because the post never got to that point in the processing (those are logged when the post is delivered to the list members).
Could you please help me out if I have missed any point or improperly understood the mail flow while using the mailman 3?
There was probably some exception in processing causing the message to be shunted. If so, the message is in the shunt queue and there is an entry in mailman.log for the exception and shunting with a traceback from the exception which will help in diagnosing the reason.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- Thanks & Regards, Shashi Kanth.K 9052671936
On 7/7/20 10:23 AM, Shashikanth Komandoor wrote:
I did not see any log records based on that message id in mailman.log. There is a lot much of shunt queue but I don't see any file with the required message id. The same is the bad queue also.
The message-id will not be logged in mailman.log for these issued.
For each such issue, there will be a log message indicating the
exception with a traceback and a 'shunting' message. To see the actual
problem message, you can use mailman qfile to examine the shunted .pck
file.
I find below two lines at that particular time stamp by when the log recorded in vette.log
*Uncaught runner exception: sequence item 0: expected str instance, Header foundTypeError: sequence item 0: expected str instance, Header found*
But I am not sure if the above lines are related to that missing message or not.
Almost certainly, but examine the shunted message with mailman qfile
to be sure.
I am using postgresql as database. FYI, if it brings an idea to you to help me.
That's not relevant to this issue.
Examine the tracebacks and shunted messages. If the problem is not obvious from that, you can post here for help. We need the complete error message with full traceback and the raw message text. For the message, we are primarily interested in all the headers including sub-part headers. Sub-part bodies can be truncated and headers sanitized for privacy if necessary, but the fewer changes you make to the raw message text, the better.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
To follow up, I received the traceback and the dump of the shunted message off-list. The traceback is
Jul 07 21:36:47 2020 (26815) Uncaught runner exception: sequence item 0: expected str instance, Header found
Jul 07 21:36:47 2020 (26815) Traceback (most recent call last):
File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 173, in _one_iteration
self._process_one_file(msg, msgdata)
File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 266, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
File "/var/lib/mailman/mailman/src/mailman/runners/pipeline.py", line 37, in _dispose
process(mlist, msg, msgdata, pipeline)
File "/var/lib/mailman/mailman/src/mailman/core/pipelines.py", line 50, in process
handler.process(mlist, msg, msgdata)
File "/var/lib/mailman/mailman/src/mailman/handlers/avoid_duplicates.py", line 59, in process
addrs = getaddresses(msg.get_all(header, []))
File "/usr/lib64/python3.6/email/utils.py", line 112, in getaddresses
all = COMMASPACE.join(fieldvalues)
TypeError: sequence item 0: expected str instance, Header found
Jul 07 21:36:47 2020 (26815) SHUNTING: 1594138007.5613732+1a5932f41fb4cfcd18c9b0b0ac6f999c84408577
This was apparently caused by an invalid RFC 2047 encoded To: header which encoded the entire header including the address as one base64, unknown-8bit character set encoded word. However, despite trying with several different Python versions, I was unable to recreate the TypeError, so the reason for this exception remains unknown.
participants (2)
-
Mark Sapiro -
Shashikanth Komandoor