Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.18

smtp-server-tls-max-version

Global

The upper bound of the TLS version on reception
in the configuration this is a linesmtp-server-tls-max-version none, which behaves as tlsv1.3inside the block Global
Which version not to go above on reception

The second bound of the range for incoming connections. The values are the same four; there is no default, that is, the ceiling is unlimited and in practice equals tlsv1.3.

Limiting it from above is almost never needed. The normal behavior is to negotiate the newest version both sides understand. A reason appears when a submitting platform announces tlsv1.3 but fails on it: this happens with old libraries with partial support.

This is a workaround for someone else’s breakage, not a security setting.

The main trap is leaving the limitation forever. The platform gets updated, the ceiling stays, and submission goes over a lower version than possible for years. The line is set for a specific reason and removed when the reason is gone.
What the Hub does. It does not write it: the ceiling is unlimited, and that is right — the node negotiates the newest version the platform understands. A limitation may be needed pointwise and temporarily.
Recommended values

Set it only for a reason:

Value When
not set (default) always
tlsv1.2 the platform announces 1.3 and fails on it

And write the reason alongside, as a comment with a date: otherwise there will be nobody to remove the line a year later.

The values and the absence of a default come from the manual (§ 3.3.1.18). The advice to write down the reason is ours.
Example configuration
# a workaround for a submitting platform's breakage, with the reason alongside
smtp-server-tls-max-version tlsv1.2   # the platform fails on 1.3, checked 28.08
The comment matters more than the line: without it nobody will understand whether the limitation can be removed after the platform is updated.
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 ends1 mistake▶

Limiting the ceiling “just in case”

our experience

What it costsSubmission stays on the old version forever. The platform updates, while the node keeps accepting what it was told to years ago.
How to spot itThe negotiated version on reception is lower than on sending.
How to do it rightDo not set it without a specific reason; provide whatever is set with a comment with the date and cause.
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
smtp-server-tls-max-version { tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3 }
Values
tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3
Default
none, which behaves as tlsv1.3 § 3.3.1.18
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive is written at the root of the file, in the Global section, and applies to the whole node. An individual listener has its own line — tls-max-version in <smtp-listener> — and it overrides the general one for connections to that address and port.
⇄

Related directives

1 relation

Works together with

smtp-server-tls-min-versionGlobalThe other bound of the same range; together they set which versions the node is willing to accept. § 3.3.1.17

How to check on the node
Checked by trying to connect with the newest version:
openssl s_client -starttls smtp -connect localhost:25 -tls1_3
A refusal means the ceiling is lowered. If it is lowered without a recorded reason, most likely the reason is long gone, and it is time to remove the line.
◇

What else to read

3 articles

◇Submission over HTTPS on its own listener, modeled on SparkPostA separate entry point: its own listener with a certificate, its own keys and a reserved source name through which the usual submission settings apply to such mail.◇The receiver declares an encryption requirement on its websiteThe node fetches the recipient domain’s policy over HTTPS and, if it is in enforce mode, delivers only when the MX matches, the connection is encrypted and the certificate is verified.◇The receiver declares an encryption requirement in its DNS zoneThe node looks at the recipient domain’s DANE records and, if STARTTLS is required, sends only over an encrypted channel with a certificate verified by fingerprint.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connection encryption
Neighboring settings of the block Global:smtp-server-tls-certificateopenssl-security-levelsmtp-server-tls-min-versionhttp-tls-min-versionsmtp-server-tls-cipher-server-preferenceAll 108 directives of the block →