Issues gathering list members
Hi
I'm with mailman 3 in a custom docker environment. And I have all services running in independent containers, and they all communicate between them.
I'm testing sending emails by telnet to a mailing list. But mailman don't send the mail to the mailing list members. But if I send the mailing list to xxxx-owners@xxxx.xx, all the owners receive the mailing list. Just when sending to the mailing list it doesn't work.
If I access in shell the mailing list mailmanclient, and I get the members, it returns all members.
I was debuging lmtp runner, and I can see that using "owners" it goes to queue "in", and Switchboard unqueue receives the message. But without "owners", it goes to "in" queue but unqueue method is not called.
How can I debug why the mailing list is never sent to members?
Another thing that is happening, is in Hyperkitty, the mailing list never shows as active. And it haves 0 participants and 0 discussions. When I'm creating a new thread, I receive the message that email was sent but it never arrives to any recipient. I thought that it requires an actual email to sent to turn the mailing list as active. But at this moment I'm not quite sure about it.
Can you point me in the right direction to understand whats happening?
kind regars,
Emanuel
On 1/20/21 7:35 AM, costavitorino@gmail.com wrote:
I was debuging lmtp runner, and I can see that using "owners" it goes to queue "in", and Switchboard unqueue receives the message. But without "owners", it goes to "in" queue but unqueue method is not called.
Do you mean 'enqueue'? In any case, , the code at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/runners/lmtp.py... sets the queue to 'in' if there is no '-subaddress' and https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/runners/lmtp.py... queues the message.
Are you saying the message never gets to the 'in' queue?
How can I debug why the mailing list is never sent to members?
First, set
[logging.smtp] level: debug
in mailman.cfg and see if you get the log message from https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/runners/lmtp.py... in Mailman's smtp.log
Another thing that is happening, is in Hyperkitty, the mailing list never shows as active. And it haves 0 participants and 0 discussions. When I'm creating a new thread, I receive the message that email was sent but it never arrives to any recipient. I thought that it requires an actual email to sent to turn the mailing list as active. But at this moment I'm not quite sure about it.
When you post from HyperKitty, the message is delivered to Mailman core, but it is not archived in HyperKitty until core sends it back to HyperKitty as part of core's processing of the message.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi
Yes, I receive the logging with: subaddress: None, queue: in
And then I have another few lines of logging, with nothing relevant ending up in Connection lost during _handle_client()
If I send with the prefix owner, after the same line I have a line saying: envsender: xxxx-teste222-bounces+emanuel-d-vitorino=telecom.pt@xxxxxxxx.pt, recipients: ['emanuel-d-vitorino@xxxxxx.pt'], size(msgtext): 464
And this one arrives at my email....
Emanuel
On 1/20/21 9:54 AM, costavitorino@gmail.com wrote:
Hi
Yes, I receive the logging with: subaddress: None, queue: in
And then I have another few lines of logging, with nothing relevant ending up in Connection lost during _handle_client()
That is normal.
If I send with the prefix owner, after the same line I have a line saying: envsender: xxxx-teste222-bounces+emanuel-d-vitorino=telecom.pt@xxxxxxxx.pt, recipients: ['emanuel-d-vitorino@xxxxxx.pt'], size(msgtext): 464
This one comes from mailman/mta/connection.py when the message is being sent to the recipients. Since you don't see that, the message never gets this far.
Since mail to -owner works, the incoming runner is processing the 'in' queue so something happens between the message being picked up from the 'in' queue and delivery.
First, check Mailman's
bin/mailman members --regular --nomail enabled list.example.com
where list.example.com is the actual list id to ensure there are members who should receive the mail. Then check Mailman's mailman.log and debug.log for clues. You may need to set
[logging.debug] level: debug
[logging.error] level:debug
To get more logging.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Hi Yes, I receive the logging with: subaddress: None, queue: in And then I have another few lines of logging, with nothing relevant ending up in Connection lost during _handle_client() That is normal. If I send with the prefix owner, after the same line I have a line saying: envsender: xxxx-teste222-bounces+emanuel-d-vitorino=telecom.pt@xxxxxxxx.pt, recipients: ['emanuel-d-vitorino@xxxxxx.pt'], size(msgtext): 464 This one comes from mailman/mta/connection.py when the message is being sent to the recipients. Since you don't see that, the message never gets
On 1/20/21 9:54 AM, costavitorino@gmail.com wrote: this far. Since mail to -owner works, the incoming runner is processing the 'in' queue so something happens between the message being picked up from the 'in' queue and delivery. First, check Mailman's bin/mailman members --regular --nomail enabled list.example.com returns two users. Mine that is also owner and another one that only subscribed the mailing list
where list.example.com is the actual list id to ensure there are members who should receive the mail. Then check Mailman's mailman.log and debug.log for clues. You may need to set [logging.debug] level: debug [logging.error] level:debug To get more logging.
Everything logging. No errors.
core/switchboard.py:97 (enqueue) Is this method that handles the queue? I'm logging the entire method, and on line 135 Im logging msgsave variable. And it's filled with some data After that, I receive DISCARD from chains/discard.py:45
If I send with prefix owner, I receive also from chains/owner.py OWNER:. .... here I believe that is the expected behavior. After this, it runs again enqueue and anything else. No DISCARD or anything
What happens before chains that could DISCARD the message? Could it be any misconfiguration of my part?
Wich methods can I check to debug whats happening?
Thank you very much Emanuel
On Wed, Jan 20, 2021, at 12:07 PM, costavitorino@gmail.com wrote:
Mark Sapiro wrote:
Hi Yes, I receive the logging with: subaddress: None, queue: in And then I have another few lines of logging, with nothing relevant ending up in Connection lost during _handle_client() That is normal. If I send with the prefix owner, after the same line I have a line saying: envsender: xxxx-teste222-bounces+emanuel-d-vitorino=telecom.pt@xxxxxxxx.pt, recipients: ['emanuel-d-vitorino@xxxxxx.pt'], size(msgtext): 464 This one comes from mailman/mta/connection.py when the message is being sent to the recipients. Since you don't see that, the message never gets
On 1/20/21 9:54 AM, costavitorino@gmail.com wrote: this far. Since mail to -owner works, the incoming runner is processing the 'in' queue so something happens between the message being picked up from the 'in' queue and delivery. First, check Mailman's bin/mailman members --regular --nomail enabled list.example.com returns two users. Mine that is also owner and another one that only subscribed the mailing list
where list.example.com is the actual list id to ensure there are members who should receive the mail. Then check Mailman's mailman.log and debug.log for clues. You may need to set [logging.debug] level: debug [logging.error] level:debug To get more logging.
Everything logging. No errors.
core/switchboard.py:97 (enqueue) Is this method that handles the queue? I'm logging the entire method, and on line 135 Im logging msgsave variable. And it's filled with some data After that, I receive DISCARD from chains/discard.py:45
If I send with prefix owner, I receive also from chains/owner.py OWNER:. .... here I believe that is the expected behavior. After this, it runs again enqueue and anything else. No DISCARD or anything
What happens before chains that could DISCARD the message? Could it be any misconfiguration of my part?
Do you see the posted message in any other queues, shunt or hold or some other?
The default owners chain doesn’t have any checks as such right now, but the default chain that accepts message has a bunch of Rules to determine what to do with the message, which is probably causing this behavior IMO.
There are a coupe of checks that can cause the message to be discarded, for example,
are you setting the From: headers (no-sender rule)?
The entire list of rules is here1 and you can find code for each of the rules 2 and also the docs for each of the rules3
If you can’t find the message in any of the queue, that means the message is being discarded. There are a few rules that can cause a direct discard if you look at 1 and some rules like member/non-member moderations, header-filters may cause a discard based on the settings.
Some other things to check would be to get the mailing list settings check the default member and non-member actions.
I hope that is helpful.
Wich methods can I check to debug whats happening?
Thank you very much Emanuel
Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-leave@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
-- thanks, Abhilash Raj (maxking)
On 1/20/21 12:07 PM, costavitorino@gmail.com wrote:
After that, I receive DISCARD from chains/discard.py:45
OK. Everything is normal, but the message is being discarded. There are many reasons why this might be the case. These include:
The poster's moderation action is discard. The poster is a list member and the list's "Default action to take when a member posts to the list" is discard. The poster is not a list member and the list's "Default action to take when a non-member posts to the list" is discard. The poster is not a list member and is in the list's "Discard these non-members" The message matches a header filter with a discard action.
There should be an entry in Mailman's mailman.log saying
DISCARD: <message-id>
To find the reason, change the line at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/chains/discard.... from
log.info('DISCARD: %s', msg.get('message-id', 'n/a'))to
log.info('DISCARD: %s, reason: %s',
msg.get('message-id', 'n/a')),
msgdata.get('moderation_reasons', 'n/a')
)-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Emanuel,
Mailman-Developers is not the best place to send this. Such problems are rarely bugs, and the active developers all read Mailman-Users frequently. You should send inquiries about installation and configuration problems to Mailman-Users@mailman3.org, because it's quite possible that other users (== site and list admins, not subscribers!) have encountered your problem. You're much more likely to get a *timely* and useful answer there, simply because there are more knowledgeable folks there -- including us.
costavitorino@gmail.com writes:
I'm testing sending emails by telnet to a mailing list.
Test-mail-by-telnet is useful to check if you can connect to Mailman on a port. Otherwise it is a risky idea unless you are a serious standards geek and a perfectionist, and even then it's a PITA. Mailman does quite a few checks on mail for distribution, and may *shunt* mail that does not conform to RFCs 821 and 822, may *discard* mail that has no body after MIME processing, and will *hold, discard, or reject* mail that matches various other rules.
I strongly recommend that you use a regular mail client, or a preformatted test mail and inject it with an MTA. Even a very simple one (Berkeley mail or mailx are quick to start) will do (as long as you stick to pure ASCII mail). That removes one variable from the diagnosis process.
Steve
participants (4)
-
Abhilash Raj -
costavitorino＠gmail.com -
Mark Sapiro -
Stephen J. Turnbull