Michael Richardson writes:
My upgrade was in part a response to the HTTP based attacks that used the signup form on mailman2 to attack people via SMTP with DOS. I know the IETF mailman2 install {now gone} had some kind of delay implemented in the web form before you could submit. I didn't understand why.
Partly it was a successor to TMDA (a challenge-response system to make senders verify they could receive mail at the source address, which weeds out a lot of spam), and partly a hack where a mailing list (which cannot be posted to) is used as a database of "community members", ie, anybody who has passed the challenge for any list is allowed to post to all the "public" lists (and vice versa: getting banned from that list is "IETF death").
I installed via debian packages, and I'd really prefer to stay with that. (Not what many maintainers would say, I know. Essential that it work if mailman3 is going to take over)
That's really Debian's problem, and it's a hard one since the whole point of using Debian packages for mission-critical applications is that they're stable. Unfortunately, the email and web environments are not, and dealing with changes in them is often quite impractical given the Debian release cycle.
I installed with sqlite3, since it seemed if all work was going to go through the mailman3 daemon, that it would handle all the concurrency issues.
The problem is that sqlite3 is intended to be a single-threaded system, but Mailman 3 by default spawns around 15 daemons that may try to access the database. I would expect you would have warnings that the database is locked frequently. Not sure what you mean by "Sometimes this goes way on it's own, but sometimes it does not".
Note that our primary purpose for the sqlite3 configuration is so unit tests don't have to spin up a full-scale PostgreSQL or MySQL database.
So I tried to switch last week from sqlite3 to postgresql. I used pgloader with a configuration file attached below.
Can't help you with that offhand, never used pgloader. Whatever method you use to load up the pg database, I would recommend doing some psql cave-diving into the PostgreSQL database to confirm it's sane before trying to configure Mailman to use that database.
ps: I'd pay some $$ money for email support consulting.
See https://wiki.list.org/COM/Mailman%20consulting%20services
Per my .sig, I'm on the list above but please go through channels linked there rather than talking to me personally about business.
-- GNU Mailman consultant (installation, migration, customization) Sirus Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan