Summary
Postfix's smtp client runs chrooted under /var/spool/postfix. Inside the chroot it cannot (a) resolve DNS or (b) read the system CA bundle. This produces two failures when sending outbound mail, and there is no persistent, documented way to fix either — the image regenerates its Postfix config on every boot, and there is no env var / template field for TLS level or DNS.
Environment
- Image: jsonbored/simplelogin-aio:latest
- Digest: sha256:76313bcfddc5285ee3bda950371baac88da18222413868afa09942ca669c9ee9
- Likely release: v4.81.4-aio.1 (image built ~6 weeks before this report)
- Note: the
org.opencontainers.image.version label reports "22.04", which is the Ubuntu base version, not the AIO release — appears mislabeled
- Host: Unraid
- Outbound via a custom relay (RELAY_MODE=custom, Mailtrap on :587)
Symptom A — DNS
All outbound is deferred with:
450 4.1.2 <recipient>: Recipient address rejected: Domain not found
getent hosts <domain> works in the container, but the chrooted Postfix cannot resolve. Workaround: create /var/spool/postfix/etc/resolv.conf with real nameservers.
Symptom B — TLS
With the default smtp_tls_security_level = secure, relay delivery is held with:
(Server certificate not verified)
update-ca-certificates reports 0 added (the CA bundle is present in the container, just not visible inside the chroot). Workaround: postconf -e 'smtp_tls_security_level = may'.
Root cause
Both stem from the smtp service being chrooted. Disabling chroot for the smtp entries in master.cf (chroot column n) lets Postfix read /etc/resolv.conf and /etc/ssl/certs directly and fixes both at once.
The real problem
Neither workaround persists: on container restart the Postfix config is regenerated and both changes are lost. There is no env var, template field, or documented mount to make them stick, so users must run an external startup script.
Suggested fix
Either disable chroot for the smtp service in the generated master.cf, or populate the chroot's resolv.conf + CA bundle at boot, and expose an env var for the outbound TLS security level (e.g. RELAY_TLS=may|encrypt|verify).
Summary
Postfix's
smtpclient runs chrooted under/var/spool/postfix. Inside the chroot it cannot (a) resolve DNS or (b) read the system CA bundle. This produces two failures when sending outbound mail, and there is no persistent, documented way to fix either — the image regenerates its Postfix config on every boot, and there is no env var / template field for TLS level or DNS.Environment
org.opencontainers.image.versionlabel reports "22.04", which is the Ubuntu base version, not the AIO release — appears mislabeledSymptom A — DNS
All outbound is deferred with:
getent hosts <domain>works in the container, but the chrooted Postfix cannot resolve. Workaround: create/var/spool/postfix/etc/resolv.confwith real nameservers.Symptom B — TLS
With the default
smtp_tls_security_level = secure, relay delivery is held with:update-ca-certificatesreports0 added(the CA bundle is present in the container, just not visible inside the chroot). Workaround:postconf -e 'smtp_tls_security_level = may'.Root cause
Both stem from the smtp service being chrooted. Disabling chroot for the smtp entries in
master.cf(chroot columnn) lets Postfix read/etc/resolv.confand/etc/ssl/certsdirectly and fixes both at once.The real problem
Neither workaround persists: on container restart the Postfix config is regenerated and both changes are lost. There is no env var, template field, or documented mount to make them stick, so users must run an external startup script.
Suggested fix
Either disable chroot for the smtp service in the generated
master.cf, or populate the chroot'sresolv.conf+ CA bundle at boot, and expose an env var for the outbound TLS security level (e.g.RELAY_TLS=may|encrypt|verify).