Tune Postfix TLS Caches Safely with tlsmgr

tlsmgr is the Postfix service you never call directly, yet it quietly runs the TLS session caches for smtp, smtpd and lmtp. This guide checks the current cache configuration, changes one setting deliberately, reloads Postfix, and confirms tlsmgr is still serving normally. About fifteen minutes, and keep a root shell or sudo handy for the reload.

Uses Postfix 3.8.6, installed from Ubuntu package 3.8.6-1ubuntu0.1. tlsmgr also maintains the pseudo-random number generator pool used by the TLS processes, another job it does without anyone asking.

1. Confirm the installed service

Both of these are ordinary, read-only checks that need no 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

Exact version and spacing can differ elsewhere; what matters is that the service map contains tlsmgr. Postfix's master process starts and supervises this service when needed. Calling tlsmgr directly is not a health check and it bypasses that supervision entirely.

2. Inspect the effective TLS settings

Use postconf -h to print values without their parameter names, showing 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

A blank line means that session cache database is unset. Here the SMTP client cache is configured while the server and LMTP caches are empty. The timeout is the maximum age of a cached session, not a guarantee that every connection gets reused.

• tls_random_source supplies external entropy.
• tls_random_bytes is the reseed read size.
• The two period settings control reseeding and saving the PRNG exchange state.

Leave those PRNG 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 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. btree: selects the database map type. Keep the file below data_directory, which Postfix itself can write to. Postfix 2.5 and later no longer opens these cache files as root, and 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 just for symmetry: pick the side that actually benefits from repeated TLS connections, and check your mail logs to confirm it did.

Undo: restore the previous value with sudo postconf -e, or set an empty value to unset it entirely:

$ sudo postconf -e 'smtp_tls_session_cache_database ='

Do not delete the cache file as part of a rollback. Let tlsmgr expire entries on its own; the file may still be in use.

4. Reload the persistent daemon

The persistent tlsmgr process does not pick up main.cf changes on its own. Validate first, then reload:

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

Both need elevated privileges. Output text varies by package and logging setup; a successful exit status matters more than the exact wording. A reload briefly asks every Postfix service to reread configuration, so time it sensibly on a busy mail host.

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

Wrong value? Restore the previous setting and run sudo postfix check then sudo postfix reload again.

5. Verify operation in logs

tlsmgr reports problems and transactions through syslogd or postlogd. Use whatever log location your distribution has set up. On a journal-based system, 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 specific cache-hit message: a missing cache entry is not itself a failure. If the log says the cache cannot be opened, check the expanded path, ownership and available space before retrying. Do not fix a permission error by making the whole directory world-writable.