trying to clean up the "held messages" mess
Hi,
I migrated a Mailman3 installation on Debian10 yesterday evening from Debian packages to PIP (thanks to [1]).
I think some bugs which existed before are now cleaned out, but mailman still threw exceptions when trying to get the "held messages".
I went through the pendedkeyvalue table of the MySQL DB to get all request ids of the held messages and their lists and discarded the messages via curl and the REST API. Mailman also logged the discarding was successful.
The amount of held messages is now reduced, but e.g. a list with 120 held messages before has till 59 held messages. And now I'm confused: where are they?
Best Regards Bjoern
[1]https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10
On 5/28/21 12:37 AM, Bjoern Franke wrote:
Hi,
I migrated a Mailman3 installation on Debian10 yesterday evening from Debian packages to PIP (thanks to [1]).
I think some bugs which existed before are now cleaned out, but mailman still threw exceptions when trying to get the "held messages".
What exceptions? Note that there is a lot of cleanup in the as yet unreleased core 3.3.5. You might consider installing that. To do so, in your virtualenv as the Mailman user do
pip install --upgrade git+https://gitlab.com/mailman/mailman
The amount of held messages is now reduced, but e.g. a list with 120 held messages before has till 59 held messages. And now I'm confused: where are they?
The held message entries are in the _request table with request_type =
- For those entries,
keyis the message-id anddata_hashis thetokenin the pended table and theidin the pended table is thepended_idof the related entries in the pendedkeyvalue table.
The message itself is stored in the file system and is pointed to by the entry in the message table with the corresponding message-id.
The exceptions you see are because entries are missing from the pended, pendedkeyvalue and/or message tables.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
What exceptions? Note that there is a lot of cleanup in the as yet unreleased core 3.3.5. You might consider installing that. To do so, in your virtualenv as the Mailman user do
the exception was:
2021-05-27 21:56:25 [FALCON] [ERROR] GET /3.1/lists/nordwest@lists.ffnw.de/held?count=10&page=1 => Traceback (most recent call last): File "falcon/app.py", line 361, in falcon.app.App.__call__ File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman/rest/post_moderation.py", line 174, in on_get resource = self._make_collection(request) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman/rest/helpers.py", line 182, in _make_collection entries = [as_dict(resource) for resource in collection] File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman/rest/helpers.py", line 182, in <listcomp> entries = [as_dict(resource) for resource in collection] File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman/rest/post_moderation.py", line 165, in _resource_as_dict assert resource is not None, resource AssertionError: None
pip install --upgrade git+https://gitlab.com/mailman/mailman
Thanks, I've upgraded to 3.3.5b1.
The exceptions you see are because entries are missing from the pended, pendedkeyvalue and/or message tables.
The exceptions are gone after the upgrade and May 28 18:48:57 2021 (18041) task runner started. May 28 18:48:57 2021 (18041) Task runner evicted 70 expired pendings May 28 18:49:11 2021 (18041) Task runner deleted 77 orphaned workflows May 28 18:49:11 2021 (18041) Task runner deleted 76 orphaned requests May 28 18:49:25 2021 (18041) Task runner deleted 71 orphaned messages May 28 18:49:25 2021 (18041) Task runner evicted expired cache entries
But since the upgrade from 3.2.1 to 3.3.x the list owners are spammed with
some.listmember@domain.tld's subscription has been disabled on nordwest@lists.ffnw.de due to their bounce score exceeding the mailing list's bounce_score_threshold.
The triggering DSN if available is attached.
and list members get corresponding notifications, but it seems Postfix did not create any bounces for them.
I did not find any related bug report yet, but maybe I missed something.
Best Regards Bjoern
On 5/28/21 11:32 AM, Bjoern Franke wrote:
But since the upgrade from 3.2.1 to 3.3.x the list owners are spammed with
some.listmember@domain.tld's subscription has been disabled on nordwest@lists.ffnw.de due to their bounce score exceeding the mailing list's bounce_score_threshold.
This should really be better documented (sigh)
Prior to Mailman 3.3.1, bounces were recorded but not processed. Beginning with Mailman 3.3.1, bounces are now properly processed. The issue is all those unprocessed bounces were still in the bounceevent table in the database and even though they were old and likely irrelevant, upon upgrade they were all processed resulting in many spurious disabling of delivery.
This is disruptive, but is a one time thing and in your case is now done.
For those who haven't yet upgraded, there are two ways to avoid this. The best way is before starting Mailman after upgrading, set
[mta]
verp_probes: yes
in mailman.cfg to enable bounce probes. With probes enabled, users whose score reaches threshold are sent a probe message and their delivery is only disabled if the probe bounces which will only happen for currently undeliverable addresses.
The other way is before starting Mailman after upgrading, run a database query similar to
UPDATE bounceevent SET processed = 1;
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Bjoern Franke -
Mark Sapiro