Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.17

smtp-server-tls-min-version

Global

The lower bound of the TLS version on acceptance
in the configuration this is a linesmtp-server-tls-min-version tlsv1.2inside the block Global
What the node is willing to accept — and why it is stricter than sending

The line sets the lower version bound for inbound connections. The values are the same four as for sending.

The default here is tlsv1.2, while for sending it is tlsv1.1 — and the asymmetry makes sense. We do not choose whom we send to: a receiver may turn out to be old, and a strict threshold would turn into lost delivery. Who submits to us, on the other hand, is known: these are our platforms, and a modern version can be required of them.

openssl-security-level applies on top of the bound — PowerMTA has its own encryption library, and its level can forbid a version this line allows.

The main trap is comparing it with the outbound setting and “aligning” them. Their defaults differ not by oversight. By lowering the acceptance threshold to tlsv1.1 “for consistency,” you allow the submitting side to use an outdated version — even though it is yours and perfectly capable of a modern one.
What the Hub does. It does not write it — it keeps the vendor default tlsv1.2. Submission comes from the fleet’s platforms, and all of them are modern; there is no reason to lower the threshold, and raising it to tlsv1.3 is risky — the submitting side’s library may turn out to be older.
Recommended values

Four values, and the decision is about the submitting side:

Value Whom you lose on submission
tlsv1 no one; and no protection is left
tlsv1.1 almost no one; weaker than the default
tlsv1.2 (default) clients with a very old stack
tlsv1.3 clients with a stack older than a few years

Check before raising it. The submitting platform is your own, and its library is known: seeing what it negotiates is cheaper than later sorting out a stopped submission.

The values and the tlsv1.2 default come from the manual (§ 3.3.1.17). The explanation of the asymmetry with sending and the advice to check the client are ours.
Example configuration
# the acceptance threshold is stricter than for sending, and that is deliberate
smtp-server-tls-min-version tlsv1.2
The default, written explicitly. We do not choose whom we send to — there the threshold is tlsv1.1; who submits to us is known, and more can be required here.
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▶

Aligning the acceptance threshold with the sending threshold

our experience

What it costsThe defaults differ on purpose. By lowering acceptance to the level of sending, you allow your own platforms to submit over an outdated version — for no reason at all.
How to spot itBoth thresholds in the configuration are tlsv1.1, and the comment says it is for consistency.
How to do it rightRestore the acceptance default. Consistency is not the goal here: the two sides solve different tasks.

Raising it to 1.3 without checking the submitting platform

§ 3.3.1

What it costsA platform with a stack older than a few years stops connecting at all. Submission stops entirely rather than degrading.
How to spot itThe platform reports a connection error right after the edit.
How to do it rightCheck what it negotiates with the command from the reference — and only then raise it.
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-min-version { tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3 }
Values
tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3
Default
tlsv1.2 § 3.3.1.17
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-min-version in <smtp-listener> — and it overrides the general one for connections to that address and port. On top of everything sits openssl-security-level: there is one per node, and it has no levels.
How to check on the node
It is checked by negotiating with the node itself — by trying to connect with an old version:
openssl s_client -starttls smtp -connect localhost:25 -tls1_1
A negotiation failure means the threshold holds. A successful connection over tlsv1.1 with the default is a reason to check whether the threshold has been lowered in the configuration or on the listener.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connection encryption