Dear Stephen,

Thank you for your reply. I have finally found what caused the problem after encountering the "HTTP Error 409: Subscription request already pending". Thanks to the archives of the mailman-users mailing list, I found out that there was a long list of pending confirmations for the slow mailinglists, mostly from non-real subscribers. Postorius functioned as expected again after having deleted these using the cli.

Best regards, Eric

-----Original Message----- From: Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> Sent: Monday, 10 February 2025 15:55 To: eric.broens@skynet.be Cc: mailman-users@mailman3.org Subject: [MM3-users] Postorius extremely slow on some of the mailinglists

Eric Broens via Mailman-users writes:

Mainly "GET /3.1/lists/<mailing_list>@<domain>/requests HTTP/1.1" takes a long time.

The only thing I can think of is that something weird is happening with requests (held messages) on those lists. The runner is waiting on the database server, and eventually timing out, I think.

I believe you will find the corresponding messages under $var_dir/messages (var_dir is usually set in mailman.cfg, if not I believe it defaults to /usr/local/mailman3/var). Unfortunately I don't know how to link those entries to the messages in that directory tree. You can "grep -ri '^list-id:.*<your.list.id>$' messages" for held posts via the problem list if you have list ID on (that's the default for recent Mailman) and if that's not going to work you could use "grep -rF 'your@list.id' messages" for a less precise search.

It's not a good idea to delete them from the file system (I think Mailman is robust to that but I'm not sure). However, if one looks like spam you could try working at a slightly lower level than Postorius by using mailmanclient directly. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/p ost-moderation.html.

If that doesn't work (for example listing the requests for a list times out the same way in mailmanclient), you could try directly querying the database server to see what's going on. The check for an unusual number of requests that might be an attack is to connect to the database server with its command line utility. I'm not on CLI terms with MySQL but for PostgreSQL it's

$ su - mailman $ psql mailman=> select mailing_list_id, count(mailing_list_id) from _request group by mailing_list_id; mailman=> select id, list_id from mailinglist;

and you can append " where id = $mailing_list_id" to the second to the second one to find the List-Id for a specific mailing list. That's just plain SQL including the count function as far as I know, so should work in any backend that Mailman can use. If you're handy with SQL you could do all that with a join but I'm not. ;-)

Any idea why this happens and how it can be solved?

Aside from a really astonishingly large number of pending requests (as tested above with count()), perhaps there's something in the requests themselves. If there aren't literally thousands of requests for a problem list you can list them with

mailman=> select key, mailing_list_id from _request;

Look for odd characters in the key field. One oddity that I'mm pretty sure is not a problem is something of the form "\r\n <message-id>" (my instance lists those fine). There's a bug in Exchange (IIRC) which sometimes includes invalid characters (specifically "[" and "]") in message IDs which I believe we worked around only quite recently, although I don't recall if it affected APIs for requests. Control characters and non-ASCII might also cause trouble,

If your database server is MySQL, is it set up to handle the full range of Unicode (I think the option is utf8mbcs)? Lacking that is known to cause problems when headers and maybe body contain emoticons or other extended Unicode characters. Again I don't recall if crashing the REST runner is a known symptom.

If none of the above works, there's always the "hit it with a hammmer" approach. Have you tried restarting both Postorius and Mailman? How about restarting the database server? How about all three?

As a last resort, it's probably possible to delete the requests from the filesystem and the database by hand. But I don't want to think about that unless absolutely necessary.

Steve