Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.16

smtp-server-tls-allow-tlsv1.3

Globaldeprecated

Whether to accept TLS 1.3 — a deprecated switch
in the configuration this is a linesmtp-server-tls-allow-tlsv1.3 trueinside the block Global
The old way to choose versions for receiving

The line allows or forbids the node to negotiate TLS 1.3 when receiving mail. Deprecated since PowerMTA 5.5: instead of five switches the vendor offers two bounds — smtp-server-tls-min-version and smtp-server-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.

Why the page is needed. Such lines live for years in configurations migrated from earlier versions. When you come across them, you need to understand not how to configure them but what to replace them with.

The main trap is mixing the two methods in one configuration. Switches and bounds describe the same thing, and the manual does not explain which setting wins. There will be no warning on apply.
What the Hub does. It does not write it: it uses a pair of bounds, or rather their defaults. It is worth recognizing the line on sight when analyzing someone else’s configuration: it means the TLS settings were migrated from a version older than 5.5.
Recommended values

Do not translate the value — migrate it:

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

The default bound for receiving is tlsv1.2, stricter than for sending. After migration this is worth rechecking: the old switches may have allowed more.

Deprecation as of version 5.5 and the default true are from the manual (§ 3.3.1). The migration table is ours.
Example configuration
# this is how it was before
smtp-server-tls-allow-tlsv1.3 true
# this is how it is written now
smtp-server-tls-min-version tlsv1.2
The lower line replaces the upper one. A pair of bounds describes the whole range at once and is easier to read than five separate 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.1

What it costsThe two methods describe the same thing, and the manual does not name the precedence between them. The configuration reads ambiguously and is applied without warnings.
How to spot itThe negotiated version matches neither what the switches allow nor what the bounds set.
How to do it rightRemove the switches entirely and keep only the bounds.

Migrating without noticing the difference in defaults

our experience

What it costsThe default bound for receiving is tlsv1.2, while the old switches may have allowed tlsv1.1. Simply deleting the lines tightens receiving — sometimes that is exactly what is needed, but it is better to know in advance.
How to spot itAfter migration some submitting clients stop connecting.
How to do it rightCompare what the switches allowed with the bound’s default, and set the bound explicitly if the behavior must stay the same.
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-allow-tlsv1.3 <boolean>
Values
yes | no | true | false
Default
true § 3.3.1.16
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, the Global section, and applies to the whole node. An individual listener has its own set of the same switches in <smtp-listener> — and the same pair of bounds to replace them.
⇄

Related directives

1 relation

Replaced by

smtp-server-tls-min-versionGlobalReplaced the whole set of five switches: the version range for receiving is set by a pair of bounds, not by five lines. § 3.3.1.16

How to check on the node
Finding such lines in the configuration is the first step of migration:
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 Global:smtp-server-tls-certificateopenssl-security-levelsmtp-server-tls-min-versionhttp-tls-min-versionsmtp-server-tls-cipher-server-preferenceAll 108 directives of the block →