Mailman 3 August 2019 - Mailman-coders

[Bug 1831777] [NEW] The site list -owner, -request and -bounces addresses in virtual domains aren't deliverable.
by Mark Sapiro Jan. 12, 2020

Jan. 12, 2020

Public bug reported: The site list -owner, -request and -bounces addresses in virtual domains are used/exposed in password reminder emails and should be deliverable. ** Affects: mailman Importance: Low Assignee: Mark Sapiro (msapiro) Status: In Progress -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1831777 Title: The site list -owner, -request and -bounces addresses in virtual domains aren't deliverable. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1831777/+subscriptions

2 3

[Bug 1785854] [NEW] TypeError from confirm CGI.
by Mark Sapiro Jan. 12, 2020

Jan. 12, 2020

Public bug reported: We have seen some massive, robotic subscribes and confirmations. In rare cases a TypeError can be thrown. This occurs because in processing, the CGI script retrieves the pending entry more than once. If the initial retrieval returns None, an appropriate message is returned, but if two clients confirm the same token at the same time, both initial retrievals may succeed, but then subsequent processing locks the list and retrieves the data again. The first client to get there processes the confirmation which removes the token. Then when the list is unlocked, the second client gets None for the pending data and throws TypeError when retrieving things from None. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1785854 Title: TypeError from confirm CGI. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1785854/+subscriptions

2 3

[Bug 1805137] [NEW] Bounces sent from opensmtpd not parsed
by Cristiano de Paula Costa Jan. 12, 2020

Jan. 12, 2020

Public bug reported: Hi, We have updated our external MTA to use OpenBSD(6.4) and opensmptd. After we updated, mailman started to send "bounce message w/no discernable addresses" messages to us (list admins). It seems that mailman is not able to parse bounce messages sent from opensmtpd. Please check an example of a bounce message from opensmtpd: Hi! This is the MAILER-DAEMON, please DO NOT REPLY to this email. An error has occurred while attempting to deliver a message for the following list of recipients: XXXXXXXXX(a)live.com: 550 5.5.0 Requested action not taken: mailbox unavailable. [VE1EUR02FT047.eop-EUR02.prod.protection.outlook.com] Below is a copy of the original message: We are using mailman 2.1.11 and I could not test the issue on version 2.1.17. But, reading the code, it seem that the problem is still there. We managed to fix the problem by editing the file 'mailman/Mailman/Bouncers/SimpleMatch.py' and including the following lines: 191,194d190 < # opensmtpd < (_c('An error has occurred while attempting to deliver a message for'), < _c('Below is a copy of the original message'), < _c('^\s*(?P<addr>[^\s@]+@[^\s@]+)')), patch follows attached Regards, Cristiano ** Affects: mailman Importance: Undecided Status: New ** Patch added: "SimpleMatch.py.patch" https://bugs.launchpad.net/bugs/1805137/+attachment/5216458/+files/SimpleMa… -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1805137 Title: Bounces sent from opensmtpd not parsed To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1805137/+subscriptions

3 7

[Bug 1818872] [NEW] Trailing spaces in the email address cause login failures.
by Mark Sapiro Jan. 12, 2020

Jan. 12, 2020

Public bug reported: Login to the user options page and private archives authentication fails if the email address has trailing spaces. ** Affects: mailman Importance: Low Assignee: Mark Sapiro (msapiro) Status: In Progress -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1818872 Title: Trailing spaces in the email address cause login failures. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1818872/+subscriptions

2 3

[Bug 1831321] [NEW] the List-Id field is filled without < and > around the list-id if the description contains unsupported characters
by Florian Schlegel Jan. 12, 2020

Jan. 12, 2020

Public bug reported: According to rfc2919 the List-Id field should be formated like this: list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF This works as long as description is left blank or contains supported characters. In my case the description was as follows: �ffentliche Supportliste As you can see the umlaut "Ö" got broken while importing the list from an old server. Unfortunately I don't know how the import was done. The field is still present but < and > around the list-id are missing. This is problematic with procmail and other mail filters. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1831321 Title: the List-Id field is filled without < and > around the list-id if the description contains unsupported characters To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1831321/+subscriptions

3 6

[Bug 1832740] [NEW] init script / mailmanctl fails to stop mailman 2, reports success
by Ian Kelling Oct. 10, 2019

Oct. 10, 2019

Public bug reported: # systemctl restart mailman Jun 13 11:43:27 lists.gnu.org systemd[1]: Stopping LSB: Mailman Master Queue Runner... Jun 13 11:43:27 lists.gnu.org mailman[31096]: * Stopping Mailman master qrunner mailmanctl Jun 13 11:43:27 lists.gnu.org systemd[1]: Stopped LSB: Mailman Master Queue Runner. Jun 13 11:43:28 lists.gnu.org mailman[31096]: ...done. Jun 13 11:43:27 lists.gnu.org systemd[1]: Starting LSB: Mailman Master Queue Runner... Jun 13 11:43:31 lists.gnu.org mailman[31153]: * Starting Mailman master qrunner mailmanctl Jun 13 11:43:31 lists.gnu.org mailman[31153]: The master qrunner lock could not be acquired because it appears as if another Jun 13 11:43:31 lists.gnu.org mailman[31153]: master qrunner is already running. Jun 13 11:43:31 lists.gnu.org mailman[31153]: ...done. At this point, ps -ef | grep mailman shows 4 mailman processes remain: /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start and 3 qrunners, like this /usr/bin/python /var/lib/mailman/bin/qrunner --runner=OutgoingRunner:1:4 -s The qrunner log does show all the pids getting the TERM signal from mailmanctl: Jun 13 11:43:27 2019 (21946) OutgoingRunner qrunner caught SIGTERM. Stopping. But only 1 actually stopped. I manually send the qrunners kill signals over and over and wait until 5 minutes later, they finally terminate and mailmanctl with them. Then I run systemctl restart mailman again, and it really starts this time: Jun 13 11:48:51 lists.gnu.org systemd[1]: Stopping LSB: Mailman Master Queue Runner... Jun 13 11:48:51 lists.gnu.org mailman[10762]: * Stopping Mailman master qrunner mailmanctl Jun 13 11:48:51 lists.gnu.org mailman[10762]: PID unreadable in: /var/run/mailman/mailman.pid Jun 13 11:48:51 lists.gnu.org mailman[10762]: [Errno 2] No such file or directory: '/var/run/mailman/mailman.pid' Jun 13 11:48:51 lists.gnu.org mailman[10762]: Is qrunner even running? Jun 13 11:48:51 lists.gnu.org mailman[10762]: ...done. Jun 13 11:48:51 lists.gnu.org systemd[1]: Stopped LSB: Mailman Master Queue Runner. Jun 13 11:48:51 lists.gnu.org systemd[1]: Starting LSB: Mailman Master Queue Runner... Jun 13 11:48:55 lists.gnu.org mailman[10775]: * Starting Mailman master qrunner mailmanctl Jun 13 11:48:55 lists.gnu.org mailman[10775]: ...done. Jun 13 11:48:55 lists.gnu.org systemd[1]: Started LSB: Mailman Master Queue Runner I'm using mailman 2.1.23-1+deb9u4+8.0trisquel1 on trisquel 8, which has Python 2.7.12. I really need to figure out a fix or workaround to this bug, waiting 5 minutes to restart mailman is no good, I run a lot of very active lists on lists.gnu.org. Can I kill -9? Can I start the mailman while the old qrunners are still exiting? How can I help debug this to find a fix? ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1832740 Title: init script / mailmanctl fails to stop mailman 2, reports success To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1832740/+subscriptions

2 3

[Bug 1839438] [NEW] ESTALE in cluster configuration
by Hiroyuki Homma Aug. 29, 2019

Aug. 29, 2019

Public bug reported: I am running a Mailman cluster with two servers sharing archives/data/lists/locks/spam directories. qfiles/logs directories are placed on each server's local volumes. Our environment is: CentOS 7.6 Mailman 2.1.29 GlusterFS 5.2 for shared volume. When I sent 1000 messages to the same list in 500 seconds (2 messages per second), about 20 messages has been shunted because of 'Stale file handle' error. Aug 06 15:14:45 2019 (15817) Uncaught runner exception: [Errno 116] Stale file handle Aug 06 15:14:45 2019 (15817) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 119, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 165, in _onefile mlist = self._open_list(listname) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 208, in _open_list mlist = MailList.MailList(listname, lock=False) File "/usr/lib/mailman/Mailman/MailList.py", line 133, in __init__ self.Load() File "/usr/lib/mailman/Mailman/MailList.py", line 692, in Load dict, e = self.__load(file) File "/usr/lib/mailman/Mailman/MailList.py", line 663, in __load dict = loadfunc(fp) IOError: [Errno 116] Stale file handle Aug 06 15:14:45 2019 (15817) SHUNTING: 1565072084.945903+914cbad4e11aaa0523b7492edba5f4836db939d1 This happens when the recipient list's config.pck file is replaced by another server while reading it. ESTALE could happen normally on shared volumes, and in most case, simply retrying open/read is sufficient to recover the error. So I think a retry logic should be implemented in MailList._load() method. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1839438 Title: ESTALE in cluster configuration To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1839438/+subscriptions

1 1