Public bug reported:
Setting localhost in postfix_lmtp works against Postfix defaults and
breaks delivery.
Reason: The Postfix lmtp client only uses dns queries by default to
search for hostnames. If the DNS server does not provide an answer for
"localhost" delivery from the lmtp client to mailman fails.
Solution: Provide "127.0.0.1" instead of "localhost". This does not
require DNS and is even faster because it saves DNS lookups.
Example:
hey2(a)mailman.state-of-mind.de
lmtp:[localhost.localdomain]:8024
** Affects: mailman
Importance: Undecided
Status: New
** Tags: 3.0 mailman
--
setting localhost in postfix_lmtp breaks delivery
https://bugs.launchpad.net/bugs/544477
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
We have seen (very rarely) cases where a recipient address has a quoted
local part such as "jr."@example.org. This results in a VERPed sender
address like list-bounces+"jr."=example.org(a)example.com which is
syntactically invalid. The VERPed sender should be "list-
bounces+jr.=example.org"@example.com in this case. I.e., the entire
VERPed sender local part should be quoted, not just the recipient local
part.
This also requires BounceRunner to recognize this and restore the
original local part.
** Affects: mailman
Importance: Medium
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/1731604
Title:
VERP fails if the recipient address local part is quoted.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1731604/+subscriptions
Public bug reported:
Various failed authentications are reported in the security log, but
there are issues:
'options' identifies itself as 'private'.
'roster' doesn't report the user if available.
'create' and 'rmlist' don't log authentication failures.
** Affects: mailman
Importance: Medium
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/1810098
Title:
Some security log messages have missing or incorrect information
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1810098/+subscriptions
Public bug reported:
When runner qrunner with --runners=All it calls all defined runners in
an endless loop[1]. Most of the time the runners have nothing to do and
quickly reach the point where they shut down again[2]. Note that this
happens before they sleep in self._snooze(), which is intended to
prevent a busy-loop. After that, the runners get started again without
delay, in an endless loop, eating up a CPU core.
As far as I know this should happen in any mailman2.1 setup when using
qrunner with --runners=All.
[1]: https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/bin/qru…
[2]: https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/Mailman…
** 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/1818205
Title:
qrunner --runners=All blocks one CPU core
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1818205/+subscriptions
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
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
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
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
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
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