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:
System: RHEL 7.7
Mailman: mailman-2.1.15-26.el7_4.1.x86_64
Description: We have 2 Mailinglist with > 7000 Members which trigger a spike in processed bounces (more than 3000 in an sinle run), followed by an Out of Memory situation in the BounceRunner and an > 20 GB bounce-event-XXXX.pck
file.
We tried to mitigate the problem by increasing the system memory, running the BoucneRunner
every minute and limiting the number of mails delivered at ounce by postfix.
But it happened again:
Dec 30 19:53:29 2019 (13392) <BounceRunner at 140395473885088>
processing 4134 queued bounces
...
Dec 30 19:53:59 mx09 kernel: [13392] 41 13392 2755797 1874474 5337 825695 0 python
...
Dec 30 19:53:59 mx09 kernel: Out of memory: Kill process 13392 (python) score 896 or sacrifice child
Dec 30 19:53:59 mx09 kernel: Killed process 13392 (python), UID 41, total-vm:11023188kB, anon-rss:7497896kB, file-rss:0kB, shmem-rss:0kB
We analyzed the bounce-event file, extracting data with "stings".
This time we extracted the postfix mail queue ids from the received headers
with our listserver. We found the following:
cat /tmp/bounce-20191230.txt | sed 's/;//' | sort | uniq -c | sort -n
1 01A7DE9314
1 10F6AE9319
1 18456E930E
1 27D0BAC960
1 3B51CE9316
1 57C2DAC992
1 5D3B2E9310
1 5EF11E9311
1 63054E9312
1 69377E9313
1 ED636E930F
2 29884E9315
2 49ECEAC98D
2 99A16A9DA7
2 (Postfix)
3 59EE1AC995
3 CEB61AC996
192 C12E9D3B48
3929 F2BEEE9318
4122 CC58AAC993
4134 6EFD1A9DA7
As the bounces the last 2 qids are from the original mail send to the list (6EFD1A9DA7),
and one of mails send by mailman to 500 members of that list (CC58AAC993).
(F2BEEE9318 and C12E9D3B48) are both bounces from members that where deliverd only once
to /usr/lib/mailman/mail/mailman bounces NAME-OF-HUGE-LIST
So from me it seems that somehow some few bounce where "multiplied" so that ~20 real
bounce produced 4134 virtual bounce.
I see the potential of a deny of service attack, as it could be used
to fill up the disk where the bounce-event files get dumped
But I don't know if this would warrant marking "This bug is a security vulnerability".
** 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/1859011
Title:
bounce mail processed multiple times -> oom crash of BounceRunner
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1859011/+subscriptions
Public bug reported:
Mailman's paths.py.in contains code to add the python site-packages dir
to the path. This uses a hardcoded "lib" prefix:
# Include Python's site-packages directory.
sitedir = os.path.join(sys.prefix, 'lib', 'python'+sys.version[:3],
'site-packages')
sys.path.append(sitedir)
On 64 bit systems this is usually lib64 and some distros started
removing the compatibility symlink lib->lib64 and split up lib and lib64
(e.g. latest Gentoo profiles). So relying on "lib" as a prefix is not
compatible any more.
Python has a function getsitepackages in the site module and I believe it's best to rely on python knowing best where its directories are. It returns an array, so this would look like this:
sitedirs = site.getsitepackages()
for sitedir in sitedirs:
sys.path.append(sitedir)
Patch attached, please apply.
** Affects: mailman
Importance: Undecided
Status: New
** Attachment added: "fix sitedir path on 64 bit filesystem layouts"
https://bugs.launchpad.net/bugs/1838866/+attachment/5280705/+files/mailman-…
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1838866
Title:
Mailman 2.1: hardcoded site-packages dir prefix doesn't work on some
64 bit filesystem layouts
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1838866/+subscriptions
Yasuhito FUTATSUKI at POEM has proposed merging lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Commit message:
Update Japanese translation
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/3774…
* Add msgstr for msgid added in rev 1829, in Japansese po file
* also, add translated comment for new setting in Japanse translation of Defaults.py.in
--
Your team Mailman Coders is requested to review the proposed merge of lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
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:
MailList.AddMember crashes with UnicodeDecodeError if all conditions below are satisfied.
* subscribe_policy of the lists is 1 or 3 (user confirmaion required)
* charset of preferred_language of the list is other than us-ascii
* translation for ' from %(remote)s' in the language contains other than us-ascii character
the patch attached may fix it.
** Affects: mailman
Importance: Undecided
Status: New
** Patch added: "fix_AddMember_patch.txt"
https://bugs.launchpad.net/bugs/1851442/+attachment/5303123/+files/fix_AddM…
** Branch linked: lp:mailman/2.1
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1851442
Title:
MailList.AddMember crashes in a certain condition
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1851442/+subscriptions
Public bug reported:
This can be prevented by refusing to pend a subscription when one is
already pending, but that means if a subscriber loses or doesn't receive
the confirmation request email, she has to wait PENDING_REQUEST_LIFE
(default 3 days) before she can request another.
It can also be avoided by setting the list's subscribe_policy to
Moderate, but that may not be desirable in many cases.
Because of these considerations, I will implement the refusal to pend a
subscription when one is already pending, but make that depend on a new
REFUSE_SECOND_PENDING mm_cfg.py setting.
** Affects: mailman
Importance: Medium
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/1859104
Title:
It is possible to mailbomb a third party by repeatedly posting the
subscribe form.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1859104/+subscriptions