scache is the Postfix daemon that keeps SMTP connections warm between delivery processes. You will confirm Postfix is managing it, inspect the cache limits on this host, and make one controlled configuration change if a longer cache lifetime is justified. Allow about fifteen minutes, plus a short maintenance window if you reload Postfix.
This guide uses Postfix 3.8.6-1ubuntu0.1 from the Ubuntu package on the reference machine. Values and log locations differ between hosts, so the read-only checks in the first steps are part of the procedure, not optional colour.
Run these as an ordinary user. They read Postfix's effective configuration and the service definition without changing anything:
$ postconf -h config_directory
/etc/postfix
$ postconf -M scache
scache unix - - y - 1 scache
$ postconf -h smtp_connection_cache_on_demand
yesThe unix service line is the detail that matters. scache is an internal Postfix service managed by master, not a network listener you start by typing scache at a prompt. The scache(8) program has generic Postfix daemon options, but its normal lifecycle comes entirely from that service definition.
Checkpoint: if postconf -M scache returns no line, stop here. The service is not currently defined in the active master.cf. Recover by restoring the distribution's Postfix service definition, then run this check again; do not invent a replacement line from memory.
Read the values that govern expiry, statistics and idle shutdown:
$ postconf -h connection_cache_ttl_limit connection_cache_status_update_time max_idle
2s
600s
100sThese are defaults from the installed configuration, not universal promises, and a cache entry can also expire because the client requested a shorter lifetime. The cache itself is organised around logical destinations, physical endpoints and connections: for SMTP a destination is the transport, domain and port, while an endpoint is the transport, IP address and port. Postfix uses those labels to decide whether a connection can be reused; the cache daemon has no idea about application-specific connection properties.
Do not increase the lifetime just because the knob exists. A longer lifetime keeps remote connections open for longer, which can be a bad fit for a relay with strict connection limits. The installed SMTP defaults give useful context:
$ postconf -h smtp_connection_cache_time_limit smtp_connection_reuse_time_limit smtp_connection_reuse_count_limit
2s
300s
0The first value limits the SMTP client's cache connection time on this host. The second limits how long a connection may be reused, and zero for the reuse count means that particular limit is not active here. Effective behaviour is bounded by both client and server-side controls, so changing only connection_cache_ttl_limit may achieve nothing at all.
Postfix's connection-cache documentation also warns that the cache is local to one machine, and that expired connections are closed without a protocol-specific handshake.
This is the first state-changing step, and it needs elevated privileges. Choose a value that fits your relay's policy; the example below sets the server-side maximum to ten seconds, so replace it with a value you have actually reviewed:
$ sudo cp --preserve=all /etc/postfix/main.cf /etc/postfix/main.cf.before-scache
$ sudo postconf -e 'connection_cache_ttl_limit = 10s'
$ postconf -h connection_cache_ttl_limit
10spostconf -e writes main.cf in Postfix's configuration syntax, but it does not make an already-running daemon pick up the new value immediately. If the edit is wrong, undo it before reloading:
$ sudo cp --preserve=all /etc/postfix/main.cf.before-scache /etc/postfix/main.cf
$ postconf -h connection_cache_ttl_limit
2sWarning: keep the backup until verification is complete. Remove it later only through your normal configuration-retention process; deleting it is irreversible.
Validate the configuration before asking the running service to pick it up:
$ sudo postfix check
$ sudo postfix reload
postfix/postfix-script: refreshing the Postfix mail systemThe reload is service-affecting, although it stops well short of a full stop and start. Schedule it with the same care as any other mail configuration change. The scache(8) manual notes that its processes run only for a limited time anyway, so a reload is the quickest way to make a main.cf change take effect.
Checkpoint: confirm the running configuration view after the reload:
$ postconf -h connection_cache_ttl_limit
10s
$ postconf -M scache
scache unix - - y - 1 scachescache reports problems, transactions and usage statistics through the system logging path, either syslogd or postlogd. Search the Postfix mail log using whatever logging system runs on your host. On a systemd host, start with:
$ sudo journalctl -u postfix --since "15 minutes ago" --no-pagerLook for Postfix SMTP deliveries and, once there is enough cache activity, hit and miss statistics. No statistics are expected when nothing has tried to use the cache yet; a quiet log is not proof the service is broken, since the cache is used on demand rather than by a permanently busy foreground process.
Do not send a message to an unknown address merely to create traffic. Use a normal, authorised delivery path and inspect the resulting Postfix delivery log. If a delivery fails, restore the backup, run sudo postfix check, and reload again.
Security boundary: the manual describes scache as non-security-sensitive and says it does not talk to the network or to local users. It may run chrooted at fixed low privilege, but it is still not a trusted process. Never use the connection cache to store passwords, SASL credentials or other security-sensitive application data, and never assume connection reuse works across multiple machines.
unix service.postfix check, and applied with a deliberate reload.