#1116630 Debian Bug Report: Silent STARTTLS Failure on Port 587

Package:
postfix
Source:
postfix
Description:
High-performance mail transport agent
Submitter:
Nick S Pizza
Date:
2025-09-29 10:15:02 UTC
Severity:
normal
Tags:
#1116630#5
Date:
2025-09-29 10:12:42 UTC
From:
To:
Summary:
Postfix silently disables STARTTLS on port 587 if the configured cert path
is missing or unreadable, without logging a fatal error or warning in
`journalctl`. This leads to a live submission socket that fails TLS
negotiation, with no indication unless mail.log is manually inspected.

Steps to reproduce:
1. Configure `main.cf` with:
   smtpd_tls_cert_file = /etc/letsencrypt/live/example.com/fullchain.pem
   smtpd_tls_key_file  = /etc/letsencrypt/live/example.com/privkey.pem

2. Ensure the cert path is missing or unreadable (e.g. permissions too
strict or file absent)

3. Start Postfix and connect via:
   openssl s_client -starttls smtp -connect localhost:587

Expected behavior:
Postfix should log a clear error in `journalctl` or fail to bind the
submission service if TLS is disabled due to cert issues.

Actual behavior:
Postfix binds to port 587, but silently disables STARTTLS. `openssl
s_client` fails with `unexpected eof while reading`, and no TLS-related
errors appear in `journalctl`. Only mail.log shows the failure, buried as a
warning.

Impact:
This leads to silent STARTTLS failure in production. The submission socket
appears functional but fails TLS negotiation, causing confusion and wasted
debugging time. The lack of systemd-visible errors makes this hard to
detect.

Related bug: Bug #1095427 describes a similar silent failure when Postfix
fails to start due to bad certs. This report documents a distinct case:
Postfix starts and binds, but disables STARTTLS silently.


Suggested fix:
Postfix should emit a fatal error or systemd-visible warning when TLS is
disabled due to cert issues, especially on submission ports.

System info:
- Debian 12 (bookworm)
- Postfix 3.7.11
- Certs managed via Let's Encrypt
- Reproducible on fresh install with missing cert path

Additional context:
This was discovered during forensic resurrection of a mail server (`scott`)
where certs were restored late in the sequence. The submission socket was
live, but TLS was silently disabled due to unreadable key permissions. No
systemd-visible error was emitted.