As someone who has just done this myself, and in similar circumstances (longtime mm2 admin moving to mm3), I agree the documentation could use some assistance. I struggled with a couple of really basic issues setting up the docker implementation - something as fundamental as understanding what the file structure on the disk should be outside of the docker containers. I got through it and took some decent notes with a goal of simplifying and automating this for myself… maybe a couple of us could contribute to fill in gaps we found.

On Apr 8, 2026, at 10:07 AM, Stephen J. Turnbull <steve@turnbull.jp> wrote:

htfoot--- via Mailman-users writes:

...

Is this just a rite of passage?

Splitting out the web UI and the archiver into separate applications was a design goal. A lot of people thought the Mailman 2 CGI design and the Pipermail archiver were "suboptimal", and we also wanted to enable commercial users to develop their own without running head-on into the GPL.

There have been a number of attempts to create a "bundled" installer over the years, but all failed because users don't want the same thing. The closest you'll get are the distro packages, but those generally lag our releases by 1-2 years (at least in stable variants). And they're no better than the ones we created ourselves from the standpoint of making everyone happy.

The closest thing to a Mailman-supported bundler now is Abhilash's proof-of-concept containerized Mailman. https://docs.mailman3.org/en/latest/install/docker.html However, a lot of users have trouble configuring the network, I'm not sure why (probably they have an existing Docker configuration with different or conflicting IP assignments which can be confusing).

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. The main hangup you're likely to encounter is that Python 3.13 (which I believe is the only packaged Python in recent Debian and Ubuntu) removed the nntplib package. That must be installed manually because our requirements files won't be updated on PyPI until the next release version.

Regards

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

---

Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...

This message sent to ddewey@cyberthugs.com

On 2026-04-08 14:38, Stephen J. Turnbull wrote:

We really only are in a position to provide good support for installations via pip, from the most recent release or from git HEADs. The virtualenv install is preferred, but as long as you provide the installation paths from mailman.cfg, we'll be able to give good support. Everything else is "we'll try, maybe you'll get lucky".

Stephen, would a prebuilt LXD-style container or VM that is respun quarterly but is still a base virtualenv setup based on Ubuntu 24.04 and otherwise fully 'setup' except for actual domain configs, etc. be useful here as an 'alternative' to 'do it yourself' but still work as a full venv setup?

That way, anyone who wants to use it would just be able to hit 'go' with a VM image (in my case a QEMU-based image) and then be able to launch a 'base' venv setup already 'ready to go' and then just run the standard 'update installation' step of pip update or whatever?

Just wondering if that'd be a useful thing to provide - not a Docker image or such, but a fully ready-to-go VM image for a virtualenv setup, ready for production usage.

Thomas

Most of that can be done with scripting in the container. It would ultimately though end up as a 'ready to go' venv environment if people want it.

I'm already working on an approach to automate install and setup of MM3 for other things I'm working on, so I'll keep this as a backup consideration for contributions.

Thomas

Sent from my Galaxy

-------- Original message -------- From: "Stephen J. Turnbull" <steve@turnbull.jp> Date: 4/8/26 16:21 (GMT-05:00) To: mailman-users@mailman3.org Subject: [MM3-users] Re: Why is it so difficult to setup Mailman3? Thomas Ward via Mailman-users writes: > Stephen, would a prebuilt LXD-style container or VM that is respun > quarterly but is still a base virtualenv setup based on Ubuntu > 24.04 and otherwise fully 'setup' except for actual domain configs, > etc. be useful here as an 'alternative' to 'do it yourself' but > still work as a full venv setup? That's a good question, but I don't know the answer. I can see that it has fewer moving parts than docker-mailman, but whether the people who find the current venv install too complex would find it appealing, I can't say. There is also the problem that you will need some way to generate the various authentication tokens and install them in the image ex post -- they can't be hard-coded. I don't think that's too hard, though. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... This message sent to teward@thomas-ward.net

On Thu, Apr 09, 2026 at 03:38:24AM +0900, Stephen J. Turnbull wrote:

Dave Dewey writes:

...

As someone who has just done this myself, and in similar circumstances (longtime mm2 admin moving to mm3), I agree the documentation could use some assistance. I struggled with a couple of really basic issues setting up the docker implementation -

*sigh* We don't support that officially, either. That's a personal project of Abhilash's. As far as I know, he still considers it a proof of concept, not a product for general use.

Please take this comment by way of feedback, presenting a point of view that is, I suspect, different from yours:

We really only are in a position to provide good support for installations via pip, from the most recent release or from git HEADs.

Which means any updates, etc, have to be done with pip -- a python thing. I have done a little python hacking but my head is not in the Python ecosystem. If I install something on Debian with apt (or Red Hat with dnf) then I do 'apt update', etc, and everything on my system is brought to the latest version.

If I install with pip: then I need to do something extra (which I will have to learn its quirks) just to bring one package, Mailman, up to date.

So: installing mailman with apt was, from my PoV, a sensible thing to do.

I accept that the Debian package of MM3 is not as good as it should be. I will not speculate why not.

-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>

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. So I used the Debian package and a lot of work was needed on top of that. There 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).

Mailman2 was a dream, simple to install and just worked. MM3 has some nice features (eg using a SQL database) but is a pig -- far more than it should be. I know other sysadmins who gave up and went with different list managers; if I was starting again I would do likewise.

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.

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.

Sirius Open Source https://www.siriusopensource.com/

Say Hi to Mark Taylor for me

-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>

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

htfoot--- via Mailman-users writes:

Ubuntu 24.04,4 appears to the latest stable release and it installed Python 3.12.3.

That's helpful. At least one avoids the confusion over nntplib.

I moved the primary server for my lists over to Discourse several years ago but still have hundreds of people who want a simple email-only service. I may just stick with mailman2 if I can get it configured.

I don't think that's packaged anywhere anymore, or Python 2 for that matter. Python 2 EOL'd in 2020 IIRC, and Mark has finally put his foot down on Mailman 2 security patches. Maybe they're available as PPAs. Or I guess one could purchase cPanel Mailman 2.2 (their legally open source but not public port to Python 3), but as far as I know that is still buggy.

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

Thomas Ward via Mailman-users writes:

Fun fact, MM2 setup was actually **much** harder than MM3 - trust me,

For a new install from source, yes. But for 2010-2020, Mailman 2.1 was slow-moving enough that with minimal effort you got a functional system from any of the major distros' packages (as long as your MTA was Postfix and your httpd was Apache, and you didn't try to configure multiple domains).

Steve

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

Mailman 2 does NOT support Python 3. That's why it's considered 'dead'.

Sent from my Galaxy

-------- Original message -------- From: htfoot--- via Mailman-users <mailman-users@mailman3.org> Date: 4/9/26 12:10 (GMT-05:00) To: mailman-users@mailman3.org Subject: [MM3-users] Re: Why is it so difficult to setup Mailman3? Has anybody successfully installed Mailman2 using Python 3? (3.12.3) I'm getting errors during configuration that are beyond my dabbler's knowledge of python to resolve. Mike Nolan _______________________________________________ Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... This message sent to teward@thomas-ward.net

...

...

...

...

"Thomas" == Thomas Ward via Mailman-users <mailman-users@mailman3.org> writes:

Thomas> On 2026-04-08 10:28, alain williams wrote:

...

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. So I used the Debian package and a lot of work was needed on top of that. There 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).

Thomas> The Debian package is inherently old and inefficient

I'm using it with Nginx, Postgresql and exim4; on sid it's at Mailman3 3.3.10 with postorious 1.3.13; it has been stable for me since the upgrade before last (before that, there was a memory leak somewhere). I did find configuring it initially a pain; the way Django works was (still is) a mystery to me; plus a couple of the upgrades have been rocky and broken things (which I expect when working with the unstable distribution)

The README in /usr/share/doc/mailman3/README.Debian was enough to get me going.

And sudo -u list /usr/bin/mailman <args>

gets you the CLI so you can do the things in the official docs.

Peter C

...

...

...

...

"Stephen" == Stephen J Turnbull <steve@turnbull.jp> writes:

Stephen> Peter Chubb via Mailman-users writes:

...

I'm using [the Debian package] with Nginx, Postgresql and exim4; on sid it's at Mailman3 3.3.10 with postorious 1.3.13;

Stephen> That's useful to know. Are you pulling specifically the Stephen> Mailman .debs from a secondary sid distribution, or are you Stephen> just populating the whole host from sid?

The whole host is running sid. I tried for a while running on the current 'stable' and just pulling in mailman3 and its dependencies from sid, but there were transitive dependencies on core libraries so ended up essentially running sid anyway.

Peter C