alain williams writes:
On Wed, Apr 08, 2026 at 11:07:42PM +0900, Stephen J. Turnbull wrote:
To the best of my knowledge, the recommended installation documents at https://docs.mailman3.org/en/latest/install/virtualenv.html are complete and straightforward for "typical" one-domain installations.
No they are not. I struggled, part of the reason is that I am not imbued in the python mindset and the documentation is written assuming that background.
*shrug* This is Un*x server software. Core is configured in .ini style. Most of the *necessary* configuration is basic mail stuff: hosts and ports. Some of it is authentication for the REST API. I can't think of anything that's really Python-specific. (And in fact, Mailman 2's configuration was Python! mm_cfg.py)
The website configuration is done in Python because Django does it that way. Pretty sure Barry would have preferred .ini (I don't think TOML was a thing back then), but it would have been a lot of work to write a translator, and probably even less intelligible, because so much Django configuration is hierarchical. I'm surprised you talk about "python mindset" though. The Django configuration is mostly strings, nested lists and dicts, and ints -- which is basically JSON.
So I used the Debian package
Which we recommend against, for good reason. We don't (can't, really) do a good job of supporting other vendors' versions, and ... well, they don't, either. :-(
are still problems: it is a resource hog and parts crash - generating large numbers of incomprehensible emails (I have talked about here, no real help).
Pointers to those conversations?
I don't know about crashes besides the OOM-killer in resource- constrained environments. Most exceptions are handled internally so you get a traceback in the logs, but that normally doesn't kill processes. And I don't know why crashes would generate "large numbers of incomprehensible emails". I don't think Mailman sends email when there is a problem. I think the default Django configuration may do so, though.
Mailman2 was a dream, simple to install and just worked.
I assure you 25 years ago it was no different from today's Mailman 3 (ie, a few years after the first production use of the software). Back then, people complained that the CGIs were a resource hog, and it sure didn't "just work" in the face of non-ASCII mail and spam -- that's why I got involved in Mailman, and later Python, development.
MM3 has some nice features (eg using a SQL database) but is a pig -- far more than it should be.
I *really* don't want to hear "should" from someone who doesn't hack Python. You're welcome to wish it was smaller, we all do. But if you can't tell me *how* to do it, don't tell me we "should".
And, seriously, the "hardware" needed is a $24/month 4GB Linode. Maybe less: I ran a (not-mission-critical) Mailman installation (and not much else!) on a 2GB DigitalOcean droplet with Ubuntu for several months. That's borderline -- I know because something would get OOM-killed once or twice a week and I'd have to restart Mailman. So something a little bit bigger than that would do. I think Linode with Debian might stretch enough to run Mailman suite, PostgreSQL, and nothing else in 2GB ($12/mo). Everyone I knew in university labs was running it in 5 or 10 year old otherwise useless hardware with 8 or 16 GB of RAM. Overkill!! ;-)
Anyway, in 2012, we wanted to scale to Fortune 100 company-sized installations without them having to hack the core. A couple years ago I worked on a site with more than 50K users and 20K lists, processing more than 1M messages (incoming) per month (heaven knows how many outgoing). It requires $24/month worth of Linode (running several extra processes to slice the out queue and a largish PostgreSQL by dedicated-to-Mailman SQL standards -- they did use HyperKitty and had several TB of archives). That's a lot of scaling for very cheap compute!
So Barry split up the core processing into runners handling queues of email messages, and of course HyperKitty and Postorius were split out into separate applications. In core, thread-per-runner was not an option then (Python had threads but the GIL was a problem), nor was async (the keywords didn't exist, the alternatives were Twisted or greenlets, and we only had one developer who could hack that stuff). So Barry went with the tried and true multiprocess model. The problem with that is that just getting the master process running gets you up to 75MB on a 64-bit machine, so you end up forking up to 20 processes x 75MB each, some of which might grow up to 125MB or so over time. At most 15-20MB of that is shared. (I think like 2 of those processes manage the web UIs and HyperKitty's background scheduler.) Doesn't fit into a Nanode, I admit.
I know other sysadmins who gave up and went with different list managers; if I was starting again I would do likewise.
That's always an option. At least with ListServs I have subscriptions on you give up a lot of functionality. Don't know about Sympa. But it's an option.
But I know that thousands of people have successfully installed Mailman 3, I assume most have migrated lists from Mailman 2. Many others are using Mailman 3 on hosting platforms.
Help here has been good & responsive (thank you) but several times I was told that because I had not followed the virtualenv instructions help was limited.
Yes, that's true. We'll give what advice we can, but if it's not a bug in our software (and it rarely is at installation, those usually show up later!), we often end up working at cross-purposes with the vendor's configuration software. Distros usually have reasons for doing it their way, but we don't know about that, and so sometimes our suggestions don't work as expected. And of course anything that involves files requires figuring out where they are, which is quite different in an FHS setup vs the virtual environment install where they're all in one place, /opt-style.
Oh: I wanted several domains, friends who also have mail list servers all seem to handle several domains so 'typical' is not what I see.
Well, single domain is a common use case from families to Fortune 100 companies. At the university where I used to work I knew of 7 single-domain installations, and I'm pretty sure there were several others. The computing services department offered Mailman lists, but that was also single-domain (still running Mailman 2 last I looked). They would also let you run your own Mailman on a VM.
Sure, I would imagine that someone who bills themselves as a "mail systems consultant" would know a lot of people managing multi-domain systems :-) but I would expect multi-domain is something you see mostly at hosting services. By nature that's going to be a relatively small installed base although they probably handle a majority of mailman lists, maybe a majority of mailman domains.
Say Hi to Mark Taylor for me
Will do.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan