Demo
Demo

Knowledge base

PMTA knowledge base›Block <smtp-listener>›Directive§ 3.3.17.10

tls-min-version

<smtp-listener>

The lower bound of the TLS version on this entry point
in the configuration this is a linetls-min-version tlsv1.2inside the block <smtp-listener>
The same name 1:<smtp-listener><transmissions-api-listener>— some of them are other settings, some are the same one
A version threshold on a separate entry point

The same bound as for the node, but for the connections of this listener. The values are the same four, the default is tlsv1.2.

Why split them. Different entry points serve different clients: submission from your own platform can require a modern version, while an entry point for an old partner can tolerate an earlier one. By separating them into listeners, each gets its own threshold.

openssl-security-level applies on top of the bound — there is one per node, and it is not split by listener.

The main trap is lowering the threshold on the shared entry point instead of a dedicated one. A line in the 0/0 listener applies to everyone who connects to the node — that is, exactly like the node-level setting. Splitting makes sense only when the entry points are different.
What the Hub does. It does not write it: the node has two listeners — the submission port and the MX port for accepting complaints and bounces — and both take the threshold from the node level. A separate threshold will be needed if the entry points get clients with different requirements.
Recommended values

The listener has its own default, the same as the node’s — the line is set here when this input should differ or when the value has been changed on the node (the manual does not promise inheritance):

Value When
do not set a single input, and the bound on the node has not been changed
tlsv1.1 or lower a dedicated input for a client with an old stack
tlsv1.2 (default) ordinary submission
tlsv1.3 an input whose clients are all definitely modern
The values and the tlsv1.2 default come from the manual (§ 3.3.17.10). The advice to separate clients by entry point is ours.
Example configuration
# a setting for one entry point, the rest take the node value
<smtp-listener 0.0.0.0:2525>
    tls-min-version tlsv1.1</smtp-listener>
A dedicated entry point for a client with an old stack: the main listener stays at the tlsv1.2 default.
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▶

Configuring the listener instead of the node when there is only one entry point

§ 3.3.17.10

What it costsThere is one listener, and configuring it is equivalent to configuring the node — but it is harder to find: it sits inside a block, not at the root of the file. The next person will look in the common settings.
How to spot itThe setting is not at the root of the file, yet the node’s behavior does not match it.
How to do it rightWith one entry point, set it at the node level. A listener setting is needed where there are several entry points and they differ.

Changing one listener and expecting all of them to change

our experience

What it costsThe line applies only to its own address and port. A neighboring entry point keeps working with the node value, and the difference shows up in the behavior of different clients.
How to spot itSome submitters see the new behavior, others the old one.
How to do it rightChange it at the node level — then the change goes to all entry points that do not set their own.
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
tls-min-version <enumeration>
Values
tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3
Default
tlsv1.2 § 3.3.17.10
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<smtp-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <smtp-listener> and applies to connections on its address and port. The manual does not promise inheritance from smtp-server-tls-min-version: the line has its own default, the same as the node’s, and “inherited from the node” is said only about tls-certificate. If you changed the value on the node, repeat it explicitly for the listener.
⇄

Related directives

2 relations

Same name in other blocks

smtp-server-tls-min-versionGlobalThe same setting at the node level; whether the listener inherits it, the manual does not say. § 3.3.17.10

Applies to

smtp-listenerGlobalThe line lives inside a listener and applies to connections to its address and port. § 3.3.17.10

Referenced from

tls-max-version<smtp-listener>The second bound of the same range: together they set which versions this input accepts. § 3.3.17.11tls-allow-tlsv1.3<smtp-listener>Replaced the whole set of five switches: the version range on this input is set by a pair of bounds. § 3.3.17.5tls-allow-tlsv1.2<smtp-listener>Replaced the whole set of five switches: the version range on this input is set by a pair of bounds. § 3.3.17.6tls-allow-tlsv1.1<smtp-listener>Replaced the whole set of five switches: the version range on this input is set by a pair of bounds. § 3.3.17.7tls-allow-tlsv1<smtp-listener>Replaced the whole set of five switches: the version range on this input is set by a pair of bounds. § 3.3.17.8tls-allow-sslv3<smtp-listener>Versions on this input are set by a pair of bounds; separate switches are no longer needed. § 3.3.17.9

How to check on the node
Check the port of the listener in question — a neighboring one may have a different value:
openssl s_client -starttls smtp -connect localhost:2525 -tls1_1
A successful negotiation means the threshold has been lowered on exactly this entry point. Check the port of the listener in question.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.◇The load balancer header at the entranceThe node reads the PROXY header at the start of an incoming connection and treats the address from it as the source; this works for both kinds of entry point.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Connect a sending platform
Neighboring settings of the block <smtp-listener>:tls-certificateimmediate-tlstls-cipher-server-preferencetls-ca-filetls-ciphersAll 18 directives of the block →