Tune Postfix TLS Caches Safely with tlsmgr

You will finish with a checked Postfix TLS cache configuration, a controlled reload, and a way to confirm that tlsmgr is still serving the daemon normally. This guide uses Postfix 3.8.6, installed from Ubuntu package 3.8.6-1ubuntu0.1. Allow about fifteen minutes and keep a root shell or sudo available for the final reload.

tlsmgr is a persistent Postfix service. It keeps optional TLS session cache entries for smtp, smtpd and lmtp, and maintains the pseudo-random number generator pool used by the TLS processes. It is not a command that you normally run by hand.

1. Confirm the installed service

These are ordinary, read-only commands. They do not need elevated privileges:

$ dpkg-query -W -f='\${Package} \${Version}\n' postfix
postfix 3.8.6-1ubuntu0.1
$ postconf -M tlsmgr
tlsmgr     unix  -       -       y       1000?   1       tlsmgr

The exact package version and spacing can differ. The important check is that the service map contains tlsmgr. Postfix's master process starts and supervises this service when it is needed. Calling tlsmgr directly is not a useful health check and bypasses that supervision.

2. Inspect the effective TLS settings

Use postconf -h to print values without the parameter names. This shows the effective configuration, including defaults:

$ postconf -h smtp_tls_session_cache_database smtp_tls_session_cache_timeout smtpd_tls_session_cache_database smtpd_tls_session_cache_timeout lmtp_tls_session_cache_database lmtp_tls_session_cache_timeout tls_random_source tls_random_bytes tls_random_exchange_name tls_random_prng_update_period tls_random_reseed_period
btree:\${data_directory}/smtp_scache
3600s

3600s

3600s
dev:/dev/urandom
32
\${data_directory}/prng_exch
3600s
3600s

Blank lines mean that the corresponding session cache database is unset. On this host the SMTP client cache is configured, while the server and LMTP cache names are empty. The timeout is the maximum age of cached session information, not a promise that every connection will be reused.

The PRNG settings are separate from TLS session caching. tls_random_source supplies external entropy, tls_random_bytes is the reseed read size, and the two periods control reseeding and saving the PRNG exchange state. Leave those values at their packaged defaults unless you have a documented platform reason to change them.

3. Choose one cache change

For an SMTP client cache, the relevant parameter is smtp_tls_session_cache_database. A local Postfix-owned path is the safe shape:

$ postconf -h data_directory
/var/lib/postfix
$ sudo postconf -e 'smtp_tls_session_cache_database = btree:\${data_directory}/smtp_scache'

This writes main.cf, so it needs elevated privileges. The btree: prefix selects the database map type. Keep the file below data_directory, which is writable by Postfix. Postfix 2.5 and later no longer opens these cache files as root; the installed tlsmgr documentation specifically recommends the Postfix-owned data directory.

For a server cache, use the same pattern with smtpd_tls_session_cache_database. Do not enable both merely for symmetry. Pick the side that benefits from repeated TLS connections, and measure the result in your mail logs.

Undo: if you decide not to keep the change, restore the previous value with sudo postconf -e. To unset a parameter, use an empty value, for example:

$ sudo postconf -e 'smtp_tls_session_cache_database ='

Do not remove the cache file as part of this rollback. It is safer to let tlsmgr expire entries, and a file may be in use.

4. Reload the persistent daemon

Changes in main.cf are not picked up automatically by the persistent tlsmgr process. First validate the configuration, then reload:

$ sudo postfix check
$ sudo postfix reload
postfix/postfix-script: refreshing the Postfix mail system

Both commands require elevated privileges. Output varies by package and logging setup. A successful command exit status matters more than the wording. Reloading briefly asks Postfix services to reread configuration; schedule it sensibly on a busy mail host.

$ postconf smtp_tls_session_cache_database
smtp_tls_session_cache_database = btree:\${data_directory}/smtp_scache

If the value is wrong, restore the previous setting and run sudo postfix check followed by sudo postfix reload again.

5. Verify operation in logs

tlsmgr reports problems and transactions through syslogd or postlogd. Use the log location configured by your distribution. On a system using the journal, this is a read-only check:

$ sudo journalctl -u postfix --since '10 minutes ago' --no-pager

Look for configuration, permission or database-map errors, not a particular cache-hit message. The absence of a cache entry is not itself a failure. If the log reports that the cache cannot be opened, check the expanded path, ownership and available space before retrying. Do not fix a permission problem by making the entire directory world-writable.