Hi,
Is maxking/docker-mailman still the recommended container deployment for a new Mailman 3 installation in 2026?
I am building a PoC on RHEL 10 using rootless Podman, with MariaDB running externally on the host (for now to ease backup issues). The repository appears somewhat inactive and its example compose file uses maxking/mailman-core:0.4 and maxking/mailman-web:0.4.
Are these images still maintained and suitable for a new deployment, or is another container image or installation method now recommended?
regards
Steven
On 2026-10-07 07:17:18 +1300 (+1300), Thing via Mailman-users wrote:
Is maxking/docker-mailman still the recommended container deployment for a new Mailman 3 installation in 2026?
Communities I'm helping run mailing lists for are using those in production, though we build our own images from the source in that Git repository we don't pull already built versions from a public container registry or anything.
I am building a PoC on RHEL 10 using rootless Podman, with MariaDB running externally on the host (for now to ease backup issues).
We also run them under Podman, but not rootless, and on Ubuntu LTS instead of RHEL and we use containerized MariaDB (we podman exec a dump and stream that to our backup client).
The repository appears somewhat inactive and its example compose file uses maxking/mailman-core:0.4 and maxking/mailman-web:0.4.
Note those are the versions of the containers, not the versions of the software they contain. See the core/requirements.txt and web/requirements.txt files for the actual Mailman component versions that go into them. Mailman doesn't make releases very often, and double-checking those lists the versions in there match the latest packaged versions of everything on PyPI.
Are these images still maintained and suitable for a new deployment, or is another container image or installation method now recommended?
I don't know for sure they're still maintained but also see no clear indication that they aren't. I'm not aware of any other popular alternatives and haven't seen a newer recommendation for containerized Mailman, but perhaps others here have.
Jeremy Stanley
Jeremy Stanley writes:
Note those are the versions of the containers, not the versions of the software they contain. See the core/requirements.txt and web/requirements.txt files for the actual Mailman component versions that go into them.
If you build your own images (I plan to do so), you can also change the pip calls to build from any git repository.
Are these images still maintained and suitable for a new deployment, or is another container image or installation method now recommended?
They're still maintained (most recent commit in June 2026). I think they're just stable enough that Abhilash isn't playing with the containers much at this point. They're not a polished product, but both docker and Mailman are strong enough for a straightforward implementation to be production-ready for "small vanilla" instances. I suspect that most enterprise installs will want to tweak them, but it's as good a place to start as any I know of.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On 2026-10-08 21:28:34 +0900 (+0900), Stephen J. Turnbull wrote: [...]
If you build your own images (I plan to do so), you can also change the pip calls to build from any git repository. [...]
Indeed, we've also done exactly that in the past in order to pick up bug fixes critical to our environment or support for newer versions of dependencies, and other times we've injected backported patches if the situation called for it. Quite a flexible solution overall, though in part because we build and deploy with a CI/CD system that speculatively exercises the resulting container images in a production-like configuration to make sure we don't break something obvious with an upgrade, patch or config change.
Jeremy Stanley
I tried to ask Claude what it will take to update Mailman 3 for Docker (https://github.com/maxking/docker-mailman/releases/tag/v0.5.2) to the newest versions of the included programs and libraries. Here is Claude's answer:
The short answer: much less than you might expect for Mailman itself, because there’s nothing newer to upgrade to. The real work is in the base OS and Django, and the Django part is blocked upstream.
The Mailman suite is already current. v0.5.2 (October 2024) pins mailman 3.3.10, mailman-hyperkitty 1.2.1, mailmanclient 3.3.5, postorius 1.3.13, hyperkitty 1.3.12 and django-mailman3 1.3.15. I checked PyPI today and those are still the newest releases of every one of them. The only exception is the separate Postorius-only image, which still installs postorius 1.3.10; bumping that to 1.3.13 is a one-line change.
Django is the real problem. Postorius, HyperKitty and django-mailman3 all require Django 4.2 or newer but below 5.1, and the web Dockerfile caps it further with Django<4.3. That leaves you on 4.2 LTS. Django 4.2’s security support ended in April 2026 and 5.0 is also end-of-life, so every Django version the suite accepts is now unsupported. You can’t fix this from the Docker side: forcing Django 5.2 LTS or 6.x past the pins means patching the three Django apps yourself and testing them. Until upstream Mailman ships releases that support newer Django, the practical choice is to stay on 4.2.x and keep the instance behind a reverse proxy.
Alpine base images are the main thing that’s actually upgradeable. v0.5.2 uses Alpine 3.20. The repo’s main branch (last touched June 2026) has moved core and web to Alpine 3.23.4 and the Postorius image to 3.21.3, but that hasn’t been tagged as a release. Alpine 3.24 is also out, with point releases up to 3.24.2 carrying OpenSSL fixes. The catch is that each new Alpine brings a newer Python, which is what tends to break builds. For example, Mailman needs the nntplib backport on Python 3.13+, and some compiled packages fail on musl.
Other things to change, all already on main:
- uwsgi is pinned to 2.0.25 because newer builds don’t compile on aarch64. PyPI has 2.0.31; you can try it if you’re on x86-64 only.
- SMTP_USE_TLS and SMTP_USE_SSL now parse correctly. In v0.5.2, any non-empty value, including "false", turned TLS on.
- urls.py adds /mailman3/ and /archives/ URL aliases.
- docker-compose gets a Postgres healthcheck, so the other services wait until the database is ready.
- The bundled compose file still uses postgres:12-alpine, which is long out of support. Moving to a current Postgres means a dump and restore (or pg_upgrade), not just changing the tag.
What it would take in practice:
- Build from main, or cherry-pick the changes above onto v0.5.2.
- Try Alpine 3.24 and fix whatever Python or musl build failures come up.
- Stay on Django 4.2.x, or take on patching the Mailman Django apps yourself.
- Upgrade Postgres separately, with a backup first.
- Run tests/test.sh and smoke-test a list end to end: post, archive, moderation and login.
Expect an afternoon for steps 1–2 and 4, plus testing. Step 3 is a real porting project unless upstream releases new versions first.
Sources:
- docker-mailman v0.5.2 and its main branch (I inspected the repo directly)
- Alpine 3.24.1 released
- Alpine 3.24.2 OpenSSL security updates
Hi,
I am or was actually in the process of rootless podman'ing these and trivy showed a lot of obsolete packages so I planed to roll these in.
However I now I see django is out of support.
:(
Is mailman3 going to be updated to > 5.2? 6? I am not deploying this as is.
regards
Steven
On Fri, 23 Oct 2026 at 05:01, jesper.holck--- via Mailman-users < mailman-users@mailman3.org> wrote:
I tried to ask Claude what it will take to update Mailman 3 for Docker ( https://github.com/maxking/docker-mailman/releases/tag/v0.5.2) to the newest versions of the included programs and libraries. Here is Claude's answer:
The short answer: much less than you might expect for Mailman itself, because there’s nothing newer to upgrade to. The real work is in the base OS and Django, and the Django part is blocked upstream.
The Mailman suite is already current. v0.5.2 (October 2024) pins mailman 3.3.10, mailman-hyperkitty 1.2.1, mailmanclient 3.3.5, postorius 1.3.13, hyperkitty 1.3.12 and django-mailman3 1.3.15. I checked PyPI today and those are still the newest releases of every one of them. The only exception is the separate Postorius-only image, which still installs postorius 1.3.10; bumping that to 1.3.13 is a one-line change.
Django is the real problem. Postorius, HyperKitty and django-mailman3 all require Django 4.2 or newer but below 5.1, and the web Dockerfile caps it further with Django<4.3. That leaves you on 4.2 LTS. Django 4.2’s security support ended in April 2026 and 5.0 is also end-of-life, so every Django version the suite accepts is now unsupported. You can’t fix this from the Docker side: forcing Django 5.2 LTS or 6.x past the pins means patching the three Django apps yourself and testing them. Until upstream Mailman ships releases that support newer Django, the practical choice is to stay on 4.2.x and keep the instance behind a reverse proxy.
Alpine base images are the main thing that’s actually upgradeable. v0.5.2 uses Alpine 3.20. The repo’s main branch (last touched June 2026) has moved core and web to Alpine 3.23.4 and the Postorius image to 3.21.3, but that hasn’t been tagged as a release. Alpine 3.24 is also out, with point releases up to 3.24.2 carrying OpenSSL fixes. The catch is that each new Alpine brings a newer Python, which is what tends to break builds. For example, Mailman needs the nntplib backport on Python 3.13+, and some compiled packages fail on musl.
Other things to change, all already on main:
- uwsgi is pinned to 2.0.25 because newer builds don’t compile on aarch64. PyPI has 2.0.31; you can try it if you’re on x86-64 only.
- SMTP_USE_TLS and SMTP_USE_SSL now parse correctly. In v0.5.2, any non-empty value, including "false", turned TLS on.
- urls.py adds /mailman3/ and /archives/ URL aliases.
- docker-compose gets a Postgres healthcheck, so the other services wait until the database is ready.
- The bundled compose file still uses postgres:12-alpine, which is long out of support. Moving to a current Postgres means a dump and restore (or pg_upgrade), not just changing the tag.
What it would take in practice:
- Build from main, or cherry-pick the changes above onto v0.5.2.
- Try Alpine 3.24 and fix whatever Python or musl build failures come up.
- Stay on Django 4.2.x, or take on patching the Mailman Django apps yourself.
- Upgrade Postgres separately, with a backup first.
- Run tests/test.sh and smoke-test a list end to end: post, archive, moderation and login.
Expect an afternoon for steps 1–2 and 4, plus testing. Step 3 is a real porting project unless upstream releases new versions first.
Sources:
- docker-mailman v0.5.2 and its main branch (I inspected the repo directly)
- Alpine 3.24.1 released
- Alpine 3.24.2 OpenSSL security updates
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 thing.thing@gmail.com
On October 22, 2026 11:39:10 AM PDT, Thing via Mailman-users <mailman-users@mailman3.org> wrote:
Is mailman3 going to be updated to > 5.2? 6?
The current GitLab head supports (actually requires) Django 5.2.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
jesper.holck--- via Mailman-users writes:
I tried to ask Claude what it will take to update Mailman 3 for Docker (https://github.com/maxking/docker-mailman/releases/tag/v0.5.2) to the newest versions of the included programs and libraries.
If you're going to ask the hallucination app (BTW, according to James Wilson of Risk Business, Risky Business Features 10/23 episode, this kind of open-ended task is something LLMs are still relatively likely to fail at), at least give it a head start and tell it to look at git HEAD of the Mailman packages, and maybe feature branches.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (5)
-
Jeremy Stanley -
jesper.holck＠ibsgaarden.dk -
Mark Sapiro -
Stephen J. Turnbull -
Thing