Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
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 analysed 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.
Version-Release number of selected component (if applicable):
mailman-2.1.15-26.el7_4.1.x86_64
How reproducible:
Every time
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Patched here:
https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1834https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1835
RHEL-7 is entering Maintenance Support 2 phase, which means that only Critical impact Security Advisories and selected Urgent Priority Bug Fix Advisories may be addressed. Please see https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase for further information.
Since this bug does not meet the criteria, we'll close it as WONTFIX. Feel free to discuss this Bug with Product Management, if this is a critical issue for the for you. Please provide business justification in such case.
This issue is fixed in Red Hat Enterprise Linux version X+1 is being tracked in Red Hat Enterprise Linux version 8
Description of problem: 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 analysed 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. Version-Release number of selected component (if applicable): mailman-2.1.15-26.el7_4.1.x86_64 How reproducible: Every time Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Patched here: https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1834 https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1835