Hello,
On Thu, Jul 18, 2024 at 09:05:28AM -0000, noc@iem.at wrote:
(my current Debian box running mailman3 is frozen at Debian/buster ("old-old-stable") because of mailman3).
Which is no longer supported (unless you subscribed to ELTS) -- for more than two weeks now.
I upgraded from Mailman2 (buster) to Mailman3 (bookworm). I took the opportunity to isolate mailman in its own container, so I really imported the lists & archives. PostgreSQL is also in another container now. The main mail server also.
So far I have not seen any issue that I could not fix easily, in part with the help of this list, which is very efficient.
what are the drawbacks, limitations, advantages and benefits of the various deployment methods?
Some of the enhancements (e.g. password forgotten mail only sent to actual account holders) will not be backported: only real security fixes will. I might apply some of those by hands, using diversions, as I was doing for Mailman2.
I will also implement a IPS using mailman's log, looks useful since, opposite to some Perl web apps I run, it does not seem there are any built-in counters in Python/Django (e.g. max number of logins per minute, hour, day; max number of e-mails to an e-mail address per minute/hour/day, etc). Maybe I just don't know enough of Django though. It's handy eg. when people mass-create accounts, etc.
The main issue I had is the enormous amount of resources (disk, database, memory) that Mailman3 uses over Mailman2 (about 10x more RAM, and the mailmanweb DB backup, zstd compressed, is 2 GBytes, where the archives were AFAIR 500M in Mailman2). With some tweaking, I could reduce the 8 GB memory footprint to 2 GB.
But as you already run Mailman3 it should not be new.