Alpine 3.21 goes EOL on 2026-11-01 and the upgrade is blocked on Dovecot 2.4

The problem

Every image builds on Alpine 3.21 (core/base/Dockerfile: ARG DISTRO=ghcr.io/mailu/alpine:3.21.7). Alpine 3.21 reaches end of life on 2026-11-01 (see https://alpinelinux.org/releases/).

After that date the 3.21 branch stops receiving security updates. Every package installed into the images — openssl, nginx, postfix, dovecot, php, python — stays at whatever version that branch last shipped, and newly disclosed vulnerabilities are never fixed. Rebuilding does not help: the pin keeps pulling the same EOL branch.

Why the version is pinned

Alpine 3.21 is the last release that ships Dovecot 2.3; 3.22 ships 2.4.1. Dovecot 2.4 refuses to start on a 2.3 configuration — plugin { } is gone, most settings moved into named sections, and several were renamed or had their meaning inverted. The base image therefore cannot move until the Dovecot configuration has been rewritten.

Two containers are affected, which is easy to miss. Besides imap, the front container runs a second Dovecot as its mail proxy (core/nginx/start.py execs dovecot -c /etc/dovecot/proxy.conf); it is the TLS endpoint and the only place where credentials are actually verified. Its dovecot-lmtpd<2.4 pin is unsatisfiable on 3.22 and fails that build outright.

Also, login has to move from podop dict to a lua script. This has already been taken care of and a pull request has been opened: PR #3967

What has to happen

1. Move Dovecot authentication from the podop dict to lua — 2.4 has no dict passdb/userdb driver. Already done by @firstred in #3967.
2. Rewrite both Dovecot configurations in 2.4 syntax (imap and the front proxy).
3. Move DISTRO to Alpine 3.22.

1 is a prerequisite and can be introduced separately. 2 and 3 cannot be separated, they have to be introduced together in one pull request.

What I can contribute

I have 2 and 3 working and am running them on a test server that receives real mail.

The configuration was written with AI assistance (Claude). Every translated setting was checked against the dovecot and pigeonhole sources rather than taken on trust — the online config upgrader from Dovecot was tried first and could not be used as is, since it dropped a lot of necessary lines.

Branch: https://github.com/Jumper78/Mailu/tree/claude/dovecot-2.4-config

Where I need help

#3967 needs two approving reviews. Per .mergify.yml that is the threshold for authors outside the trusted list, and nothing can follow until it lands.

After that, I need people to test on setups that differ from mine: other architectures, other webmails, installations that use a Dovecot override.

An open question about releases

The change is breaking for one group: users with a Dovecot override. Both overrides/dovecot/dovecot.conf and overrides/nginx/dovecot/proxy.conf have to be rewritten in 2.4 syntax, or the containers will not start.

That makes the release path a policy question I cannot answer:

• If this only goes into master, everyone running released images stays on an EOL base until the next major release.
• If it is backported to 2024.06, override users get a breaking change in a patch release.

I have no opinion on which is right, but it seems worth deciding deliberately rather than by default.