emails are not delivered to all recipients

Bug #1756009 reported by Raimonds
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
GNU Mailman
Incomplete
Undecided
Unassigned

Bug Description

Mailman often do not send emails to all addressees.
Usually a single recipient is lost, but sometimes 2 or 3.

there is a fragment from mailmans smtp log file, recipient count randomly changed from 28 to 27.
Mar 15 08:57:31 2018 (60449) <email address hidden> smtp to dml-patch for 28 recips, completed in 0.395 seconds
Mar 15 08:58:17 2018 (60449) <email address hidden> smtp to dml-patch for 27 recips, completed in 0.167 seconds
Mar 15 09:09:04 2018 (60449) <email address hidden> smtp to dml-patch for 28 recips, completed in 0.148 seconds
Mar 15 09:13:47 2018 (60449) <email address hidden> smtp to dml-patch for 27 recips, completed in 0.151 seconds
Mar 15 09:14:59 2018 (60449) <email address hidden> smtp to dml-patch for 28 recips, completed in 0.082 seconds
Mar 15 09:15:54 2018 (60449) <email address hidden> smtp to dml-patch for 28 recips, completed in 0.249 seconds
Mar 15 09:16:59 2018 (60449) <email address hidden> smtp to dml-patch for 28 recips, completed in 0.131 seconds
Mar 15 09:17:05 2018 (60449) <email address hidden> smtp to dml-patch for 27 recips, completed in 0.143 seconds
Mar 15 09:17:27 2018 (60449) <email address hidden> smtp to dml-patch for 28 recips, completed in 0.093 seconds
Mar 15 09:17:56 2018 (60449) <email address hidden> smtp to dml-patch for 27 recips, completed in 0.211 seconds
Mar 15 09:18:11 2018 (60449) <email address hidden> smtp to dml-patch for 27 recips, completed in 0.089 seconds
Mar 15 09:18:20 2018 (60449) <email address hidden> smtp to dml-patch for 27 recips, completed in 0.112 seconds
Mar 15 09:23:06 2018 (60449) <email address hidden> smtp to dml-patch for 28 recips, completed in 0.129 seconds
Mar 15 09:23:34 2018 (60449) <email address hidden> smtp to dml-patch for 28 recips, completed in 0.560 seconds
Mar 15 09:23:41 2018 (60449) <email address hidden> smtp to dml-patch for 28 recips, completed in 0.061 seconds

list_members command always shows correct members count 28.
/usr/lib/mailman/bin/list_members dml-patch | wc -l
28

OS CentOS Linux release 7.4.1708
Using Mailman version: 2.1.15 (standart centos package)

The same problem was occur on Red Hat Enterprise Linux Server release 6.9 (Santiago) Mailman version: 2.1.12

Revision history for this message
Mark Sapiro (msapiro) wrote :

There are a couple of reasons why Mailman doesn't send a post to all regular members with delivery enabled. The post can be from a member whose "Receive your own posts to the list?" option is No (not metoo checked in the admin membership list), or a member whose "Avoid duplicate copies of messages?" option is Yes (nodupes checked in the admin membership list) is directly addressed in To:, Cc:, Resent-To: or Resent-Cc: of the incoming post.

Unless you have evidence that these are not the reasons, this is expected behavior. Also note that if a member is not sent a copy because her address is in Cc: of the incoming post, that address will be removed from Cc: in the post sent to list members, so you can't tell by looking at a post received from the list if a member with nodupes set was addressed in Cc: of the incoming message.

Changed in mailman:
status: New → Incomplete
Revision history for this message
Dr. Heiko Muenkel (hm-f) wrote :

I have a similar problem. But here there are more users. According to the log file, for example, last time emails were sent to only 103 of 138 users. Probably it's always the same users who don't receive email. I have checked the settings for some of them. After that they should get emails. In the logfile I did not find any information why the emails were not sent, i.e. I did not find the email addresses of the unsent emails there.

How can I get to the bottom of the problem?

Revision history for this message
Mark Sapiro (msapiro) wrote :

The reasons for this are given in https://bugs.launchpad.net/mailman/+bug/1756009/comments/1 and in addition to those, another possibility is digest members or members with delivery disabled. What does Mailman's

bin/list_members --regular --nomail=enabled <list-name>

show. Does it list 138 members?

Revision history for this message
Dr. Heiko Muenkel (hm-f) wrote :

I am relatively sure that none of the users have changed the settings. But anyway, I checked the settings of two of the users who no longer get email (see attachment). So I don't think any of the reasons listed in https://bugs.launchpad.net/mailman/+bug/1756009/comments/1 come into question here. In the emails also only the email list was specified as recipient.
Unfortunately I did not find the bin/list_members program. Mailman is installed in two Docker containers and I have logged in there and searched with find from /.

I sent a who command for the list via email to the server. The reply email also correctly delivered the 138 members.
I also created a test list with only the two email addresses I mentioned above and with my email address. When I send an email to the test list, the email is also delivered to the two addresses.

Thanks for your help.

Revision history for this message
Mark Sapiro (msapiro) wrote :

Your options.png is from Mailman 3's Postorius. This tracker is for Mailman 2.1, not Mailman 3. Mailman 3 is at https://gitlab.com/mailman

Mailman 3's command for listing members is `mailman members`. Try

mailman members --regular --nomail=enabled <list-name>

If that doesn't list all 138, you can find the digest members with

mailman members --digest=any <list-name>

and those with delivery disabled with

mailman members --nomail=any <list-name>

Revision history for this message
Dr. Heiko Muenkel (hm-f) wrote :

Oh, I didn't expect that version 2 was still alive. I'm sorry about my mistake.

Thank you very much for help and the hint to the commands.

With the help of the commands, I was able to determine that quite a few users were actually disabled, although this was not clear from the settings. Probably the users were disabled after several emails could not be delivered to them.
After I explicitly enabled them in the interface, they are no longer disabled according to the commands. I hope now that all problems are solved with that.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.