Demo
Demo

Knowledge base

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

tls-allow-tlsv1.3

<smtp-listener>deprecated

Whether to accept TLS 1.3 on this input — a deprecated switch
in the configuration this is a linetls-allow-tlsv1.3 trueinside the block <smtp-listener>
The same name 1:<smtp-listener><transmissions-api-listener>— some of them are other settings, some are the same one
The old way to choose versions for the listener

The line allows or forbids negotiating TLS 1.3 on connections of this listener. Deprecated since PowerMTA 5.5: instead of five switches the vendor offers two bounds — tls-min-version and tls-max-version.

One of five such sets of five in the configuration. The same switches exist for sending to the receiver, for receiving mail by the node, for the listener, for the Transmissions API input and for the web monitor — twenty-five lines in five places. The migration rule is the same everywhere.

The main trap is mixing the two methods in one block. Switches and bounds describe the same thing, and the manual does not name the precedence between them. There will be no warning on apply.
What the Hub does. It does not write it: it uses the bounds, or rather their defaults. It is worth recognizing the line on sight when analyzing someone else’s configuration.
Recommended values

Do not translate the value — migrate it:

What it was What it became
tlsv1.2 and tlsv1.3 allowed tls-min-version tlsv1.2
all from tlsv1 allowed tls-min-version tlsv1
tlsv1.3 forbidden tls-max-version tlsv1.2
everything by default neither line is needed

The listener’s default bound is tlsv1.2. After migration this is worth rechecking: the switches may have allowed more.

Deprecation as of version 5.5 is from the manual (§ 3.3.17). The migration table is ours, common to all five such sets in the configuration.
Example configuration
# this is how it was before
<smtp-listener 0.0.0.0:25>
    tls-allow-tlsv1.3 true</smtp-listener>

# this is how it is written now
<smtp-listener 0.0.0.0:25>
    tls-min-version tlsv1.2
</smtp-listener>
The lower block replaces the upper one. A pair of bounds describes the whole range at once and reads more easily than five switches.
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▶

Leaving switches next to bounds

§ 3.3.17

What it costsThe two methods describe the same thing, and the manual does not name the precedence between them. The configuration reads ambiguously.
How to spot itThe negotiated version matches neither what the switches allow nor what the bounds set.
How to do it rightRemove the switches and keep only the bounds.
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-allow-tlsv1.3 <boolean>
Values
yes | no | true | false
Default
true § 3.3.17.5
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 bounds that replace it are written in the same block; the manual does not promise them inheritance from the node level.
⇄

Related directives

1 relation

Replaced by

tls-min-version<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.5

How to check on the node
Finding such lines is the first step of migration; the configuration has five sets of them, in different places:
grep -rn "tls-allow-" /etc/pmta/
Switches for sending, receiving by the node, the listener, the Transmissions API input and the web monitor will be found. They should be replaced with pairs of bounds, and the result checked by negotiation.
◇

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
safe: a wrong value breaks nothing
Scenarios
Connection encryption
Neighboring settings of the block <smtp-listener>:tls-certificatetls-min-versionimmediate-tlstls-v1.3-ciphersuitestls-ca-fileAll 18 directives of the block →