Postfix 3.11.0’s Move Away From BerkeleyDB: What It Means for Your Mail Server
When Postfix drops support for BerkeleyDB, administrators who rely on hash and btree lookup tables must act before the feature disappears completely. This release shows how to migrate to LMDB or CDB with minimal downtime and outlines the TLS adjustments that will make mail delivery safer but also a bit stricter.
Why the BerkeleyDB Migration Isn’t Just Another Feature Update
Several Linux distributions have started to remove the BerkeleyDB libraries from their repositories. As a result, Postfix can no longer use hash: or btree: lookup tables, which are the default for many mailing lists and alias files. A small server that had just installed a new Postfix package saw its list additions fail because “postmap hash:/etc/postfix/aliases” returned an error every time it tried to write the file. The problem was not a bug in Postfix; it was a missing dependency.
Migrating now is preferable to waiting until support is officially removed. By switching to LMDB, the server avoids downtime that would otherwise occur when the next upgrade tries to use hash: again. The command postconf -e smtpd_alias_maps=hash:/etc/postfix/aliases can be replaced with postconf -e smtpd_alias_maps=lmdb:/etc/postfix/aliases. This change forces Postfix to look for a file that is compatible with LMDB’s format and eliminates the need for any intermediate script.
TLS Defaults: “May” Is Still Too Lenient For Some Setups
Postfix 3.11.0 changes the default value of smtp_tls_security_level from the old “may” to a stricter stance when the system is built with TLS support and uses compatibility level 3.11 or higher. If an organization has a policy that requires encrypted transport for all outgoing mail, this new default ensures compliance without additional configuration.
A server running Postfix on a corporate network with strict security guidelines experienced a spike in failed deliveries after the change. The culprit was a relay host that did not advertise DANE support; because the client now enforces TLS when possible, it rejected messages from hosts lacking proper certificates. Adjusting smtp_tls_security_level to “encrypt” or disabling smtpd_tls_security_level on the receiving side can bring the behavior back in line with expectations.
Requiring TLS (REQUIRETLS) and the New STS Enforcer
Postfix now supports RFC 8689’s REQUIRETLS verb, which demands that every server along the forward path authenticates itself with DANE or STS before mail is accepted. While this raises the bar for security, it can also cause massive delivery hiccups if any hop in the chain fails to announce the requirement or lacks a valid certificate.
The new smtp_tls_enforce_sts_mx_patterns parameter (default “yes”) forces the client to connect only to MX hosts that match STS policy patterns. If a host does not match, the old behavior is preserved: Postfix will still try any listed MX and perform generic certificate validation. Administrators can tweak this setting by adding or removing patterns in main.cf, which helps avoid unintended rejections when some legacy servers are still on the network.
Post-Quantum Cryptography and Protocol Ossification
With OpenSSL 3.5+ available, Postfix’s tls_eecdh_auto_curves default is adjusted to mitigate protocol ossification problems that arise when a TLS hello message exceeds one Ethernet‑TCP segment. While this feature may seem futuristic, real-world evidence shows that certain firewalls strip packets larger than 1500 bytes, causing handshake failures on older hardware. The new setting prevents those misbehaving devices from dropping legitimate connections.
JSON Output: Useful for Developers but Overkill for Everyday Admins
The release adds JSON output options to postconf, postalias, and related commands. While the ability to pipe configuration data into scripts is handy for automation experts, most administrators will find it unnecessary because they rarely parse configuration files in bulk. The additional flags add noise without delivering tangible benefits to the typical user.
Milter Error Handling: A Practical Change
Milters that previously returned tempfail on long‑lived SMTP connections now receive a shutdown action, which disconnects the client immediately. For mail systems that process large volumes of spam or malformed messages, this change reduces resource consumption and prevents slow‑downs caused by lingering connections.
That’s the lowdown on what Postfix 3.11.0 brings to your mailbox and why it matters. You can download the source code of the new release from here.
