I've been using Mailman2 for probably 20 years, and recently I've been looking to move up to Mailman3 on an Ubuntu system.
I think I've got the mailing list core part working, but the instructions for setting up the web part(s) are either inscrutable or incomplete, if not both.
Is this just a rite of passage?
On a production setup where you want to be certain to get everything right, I think it's important to script the installation process in a tested and replicable way... Suggestion: use our ansible role: https://github.com/cppalliance/ansible-mailman3
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
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
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.
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".
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.
That would be a big step toward official support. You're welcome to discuss the docker installation (and distro packages, for that matter) here, but issues and MRs should be filed to the docker-mailman project on GitHub, not the Mailman project on GitLab (or the distro package, in that case).
It would also be very helpful to provide advice on Docker networking (basic theory of operation, list of IPs that need to be coordinated across containers come to mind). I hadn't heard of the host filesystem issue before (but I easily imagine that could be a source of confusion), while "Docker networking hates me" is a FAQ.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
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
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
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>
alain williams writes:
So: installing mailman with apt was, from my PoV, a sensible thing to do.
Of course it is a sensible thing for you to do. Nobody is telling you not to do that. Package managers are a wonderful invention, and if the package available meets your needs, use the manager you're most comfortable with. We just say if you want *us* to help you with somebody else's package, you have to expect that we're not going to do as good a job as if you use our recommended version.
We get bug reports about the documentation all the time, we fix them as we have time available -- I merged six of them last night. But that's not what's happening here. You said that the virtual environment installation instructions are not easy to understand. On the one hand, what are we supposed to fix? On the other, why would you expect them to be easy to understand when you say that "python3 -m pip install mailman" is more effort to learn than you're willing to spend when you already know "apt"? There's nothing wrong with preferring apt because you know it, but don't you see when you say the virtualenv installation is too hard to understand, we're not going to take that as an actionable bug report?
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
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>
Adding my $0.02:
On Wednesday, April 8th, 2026 at 10:29, alain williams addw@phcomp.co.uk 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).
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.mailto:rm55@cybercontradiction.org
I replaced a long-time Mailman2 install (20+ years) with Mailman3 at the beginning of March.
I made a go at the official installation and balked. I didn't want all of the "venv" Python stuff, basically. It seems to me that is an advanced option, but it is provided as the official option.
I found an RPM that hasn't made it yet to any official repo. I'm looking for any official announcements for updates to Mailman3 (especially security) and will make my own updated RPM if I need to. Being able to use a package manager for a repeatable (and non-complex) install is probably what a lot of sites are looking for. I also like the use of systemd mechanisms including timers, which makes Mailman fit in better with the rest of the OS.
None of that means ingratitude to the Mailman3 developers and to whoever wrote the official install docs. I agree though that the complexity of the Mailman3 install is probably what keeps sites on Mailman2.
Rudolph T. MaceykoMy Contact InfoFind a Scouting America unit near you
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
Ubuntu 24.04,4 appears to the latest stable release and it installed Python 3.12.3.
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.
Mike Nolan
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
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).
The Debian package is inherently old and inefficient.
If you want specific help with the venv setup and such, I am able to try and help you with any specific issues you're having - the venv documentation for installation actually IS pretty straightforward, but you have to work around some specific Pythonisms in the virtualenv. And then do some SystemD magic to make it work.
The amount of actual Python knowledge you need is limited as long as you follow the steps specifically. Reach out independently if you want me to try and assist you more hands-on (schedule time with me, be more detailed in what errors and issues you came up with, etc.)
And if the documentation actually needs rewriting, I can try and take a stab at it.
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. Fun fact, MM2 setup was actually **much** harder than MM3 - trust me, I've had to set up MM2 to debug things for clients of mine who were using MM2, and they're on MM3 now and are worshiping it in comparison to MM@.
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
"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
participants (8)
-
alain williams -
Dave Dewey -
htfoot＠gmail.com -
Peter Chubb -
Rudolph T. Maceyko -
Sam Darwin -
Stephen J. Turnbull -
Thomas Ward