Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.108.5

reuse-ssl-session

<domain>set by the Hub

Whether to reuse the parameters of a previous TLS session
in the configuration this is a linereuse-ssl-session falseinside the block <domain>
A minor optimization with a very narrow scope

When reconnecting to the same host soon after a previous session, you can skip the full handshake and use the earlier parameters. The line allows this. The default is false.

Two limitations make it almost unnecessary. First: on TLS 1.3 the mechanism does not work and the directive is ignored — and 1.3 is increasingly what gets negotiated. Second: the receiver must be able to do the same, and the manual says plainly that one such receiver is known — gmail.com.

The vendor advises enabling it only for those known to support it.

The main trap is lowering the version ceiling for the sake of this optimization. The logic “let’s enable reuse, and limit the version to 1.2 for that” trades the noticeable for the negligible: a handshake in 1.3 is already shorter than an abbreviated one in 1.2.
What the Hub does. It writes no, explicitly, in all fifteen blocks of the policy template, including the general one. Not because the mechanism is harmful, but so that the configuration reads without knowing the defaults: the line sits next to the other connection settings and says the question has been considered.
Recommended values

The value is boolean, and there is exactly one meaningful case:

Value When
no (default) always
yes the receiver is known to support it — according to the manual, that is gmail.com

And only with a version below 1.3. On 1.3 the line is ignored, so enabling it together with modern versions is pointless.

The false default, ignoring on TLS 1.3 and the mention of the only known receiver come from the manual (§ 3.3.10.108.5). The advice not to touch the version ceiling for this is ours.
Example configuration
# an explicit “no” — this way the configuration reads without knowing the defaults
<domain $mailru>
    use-starttls yes
    reuse-ssl-session no</domain>
That is exactly how it stands in the Hub’s policy template. Enabling it makes sense only for a receiver known to support reuse — and only if connections go over a version below 1.3.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Enabling it for all receivers

§ 3.3.10.108.5

What it costsAccording to the manual, one known receiver supports the mechanism. For the others the line is either ignored or leads to an extra attempt on every reconnection.
How to spot itThe line is in <domain *>.
How to do it rightKeep the default everywhere except for receivers known to support it.

Lowering the version ceiling for the sake of the optimization

our experience

What it costsConnections move to TLS 1.2 for the sake of an abbreviated handshake, although a full handshake in 1.3 is already shorter. The result is a lower version with the same or worse outcome.
How to spot itThe receiver has smtp-tls-max-version set to tlsv1.2, and the comment mentions performance.
How to do it rightRemove the ceiling limitation and keep this line’s default.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
reuse-ssl-session <boolean>
Values
yes | no | true | false
Default
false § 3.3.10.108.5
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and merges by the usual rule of receiver blocks: the most exact match by receiver name wins. The same three levels apply by sending address. On version 1.3 the directive is ignored regardless of the level it is set at.
⇄

Related directives

1 relation

Depends on

smtp-tls-min-version<domain>Session reuse does not work on version 1.3, and therefore depends on which versions are allowed. § 3.3.10.108.5

How to check on the node
Checked indirectly by the negotiated version: if it is 1.3, the line takes no part:
pmtaacctfind --output csv[rcpt,dlvTlsProtocol] /var/log/pmta/acct-*.csv | head -20
Version TLSv1.3 means reuse is not applied, whatever is in the configuration. The node does not show a separate counter of abbreviated handshakes. The version column is filled only if dlvTlsProtocol is named in record-fields; on Hub nodes it is not named.
◇

What else to read

3 articles

◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.

In the Hub
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Tune the pace for a provider
Neighboring settings of the block <domain>:smtp-tls-min-versionuse-starttlsuse-daneuse-mta-stsrequire-starttlsAll 135 directives of the block →