Demo
Demo

Knowledge base

PMTA knowledge base›Block <transmissions-api-listener>›Directive§ 3.3.21.2

tls-allow-tlsv1.3

<transmissions-api-listener>deprecated

Whether to accept TLS 1.3 on the Transmissions API input — a deprecated switch
in the configuration this is a linetls-allow-tlsv1.3 trueinside the block <transmissions-api-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 API input

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

The default is true. The newest version, on by default. Forbidding it is the only reason an upper bound makes sense on this input.

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: submission here goes over SMTP, and there is no API input block in the configuration. 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 nothing needs to be written, this is the default
all from tlsv1 allowed tls-min-version tlsv1
tlsv1.3 forbidden tls-max-version tlsv1.2
everything by default neither line is needed

The default lower bound for this input is tlsv1.2. After migration this is worth rechecking: the switches may have allowed more.

Deprecation as of version 5.5 and the defaults are from the manual (§ 3.3.21.2). The migration table is ours, common to all five such sets in the configuration.
Example configuration
# this is how it was before
<transmissions-api-listener 0/0:443>
    tls-allow-tlsv1.3 true</transmissions-api-listener>

# this is how it is written now
<transmissions-api-listener 0/0:443>
    tls-min-version tlsv1.2
</transmissions-api-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 ends2 mistakes▶

Leaving switches next to bounds

§ 3.3.21.2

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.

Migrating the API input lines together with the mail listener lines

our experience

What it costsThe names match word for word, but the blocks are different: these are two independent inputs. Migrating “in a batch” changes the behavior of SMTP submission along with API submission.
How to spot itAfter the edit, negotiation changed where it was not touched.
How to do it rightMigrate each block separately and check which of them the line was in.
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.21.2
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<transmissions-api-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
No inheritance: the line applies inside its own <transmissions-api-listener>. The bounds that replace it are there too, in the same block, and do not extend to other inputs.
⇄

Related directives

1 relation

Replaced by

tls-min-version<transmissions-api-listener>Replaced the whole set of five switches: the version range on this input is set by a pair of bounds. § 3.3.21.2

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 <transmissions-api-listener>:tls-certificatetls-min-versiontls-max-versiontls-cipher-server-preferencetls-ciphersAll 15 directives of the block →