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