Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.108.11

smtp-tls-min-version

<domain>

The minimum TLS version toward the receiver
in the configuration this is a linesmtp-tls-min-version tlsv1.1inside the block <domain>
Which version not to go below

The line sets the lower bound: the node will not negotiate versions older than the one specified. The values are tlsv1, tlsv1.1, tlsv1.2, tlsv1.3. The default is tlsv1.1.

It replaced five separate switches. Before version 5.5 each protocol version was enabled with its own line — smtp-tls-allow-tlsv1 and its relatives; all of them were deprecated in favor of this pair.

The threshold is not the only restriction. openssl-security-level can forbid a version earlier: PowerMTA has its own encryption library built into the distribution, and its security level applies on top of everything. Allowing tlsv1 with this line and getting a refusal at the library level is a common sequence of events.

The main trap is raising the threshold without noticing the loss of receivers. tlsv1.2 looks harmless and changes nothing at large receivers, but small corporate mail servers with TLS 1.0 still exist. With require-starttls on, such messages will not go out at all; with it off, they will go out in plain text, which is usually worse than old encryption.
What the Hub does. It does not write it — it leaves the vendor default tlsv1.1. We have no reason to raise the threshold: large receivers already negotiate tlsv1.2 or tlsv1.3, and for small ones a raised threshold would mean either unencrypted delivery or no delivery at all. The receiving side is configured separately — smtp-server-tls-min-version.
Recommended values

Four values, and the choice between them is about the tail, not the majority:

Value Who you lose When to use it
tlsv1 no one a receiver with a very old stack, pointwise
tlsv1.1 (default) almost no one a regular fleet
tlsv1.2 small mail servers with an old stack a client’s or regulator’s requirement
tlsv1.3 a noticeable share only for a specific receiver that supports it

Look at it together with require-starttls: a raised threshold without the requirement turns into unencrypted delivery, and with the requirement — into non-delivery.

The values and the tlsv1.1 default come from the manual (§ 3.3.10.108.11). The breakdown by losses and the link with the requirement are ours.
Example configuration
# the threshold is raised only for a receiver that can certainly handle it
<domain hotmail.com>
    use-starttls yes
    smtp-tls-min-version tlsv1.2</domain>
Such a line is not put in <domain *>: for small mail servers with an old stack, messages would then either go out in plain text or not go out at all — depending on what require-starttls is set to.
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▶

Raising the threshold in the common recipient block

our experience

What it costsLarge receivers will not notice; small ones will stop receiving mail or will start receiving it in plain text. Which of the two depends on require-starttls, and both outcomes are bad.
How to spot itQueues to small domains grow, or the protocol version disappears for them in accounting.
How to do it rightRaise the threshold for a specific receiver, not for everyone. Leave the common block at the default.

Looking for the cause of a refusal in this line when the library is to blame

§ 3.3.1

What it costsopenssl-security-level applies on top and can forbid a version that this line allows. The permission in the configuration stays visible and creates the impression that the version is available.
How to spot itThe version is allowed, yet negotiation still fails.
How to do it rightCheck the library’s security level: there is one for the whole node, and it changes the available set of versions and ciphers.
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-tls-min-version <enumeration>
Values
tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3
Default
tlsv1.1 § 3.3.10.108.11
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and merges by the usual rule for recipient blocks: the most precise match by receiver name wins. The same three levels apply by sending address — node, <virtual-mta-pool>, <virtual-mta>. On top of all this stands openssl-security-level: it is not inherited with the blocks but applies to the whole node.
⇄

Related directives

3 relations

Depends on

openssl-security-levelGlobalThe library’s security level may forbid a version before this setting even comes into play. § 3.3.1.51

Same name in other blocks

smtp-server-tls-min-versionGlobalThe same threshold from the other side: this one is about outbound connections, that one about the node receiving mail. § 3.3.1.17

Works together with

smtp-tls-max-version<domain>The other bound of the same range; together they define which versions the node is willing to negotiate. § 3.3.10.108.12

Referenced from

reuse-ssl-session<domain>Session reuse does not work on version 1.3, and therefore depends on which versions are allowed. § 3.3.10.108.5smtp-tls-allow-tlsv1<domain>Replaced the whole set of five switches: the version range is set by a pair of bounds, not by five separate lines. § 3.3.10.108.6smtp-tls-allow-tlsv1.1<domain>Replaced the whole set of five switches: the version range is set by a pair of bounds, not by five separate lines. § 3.3.10.108.7smtp-tls-allow-tlsv1.2<domain>Replaced the whole set of five switches: the version range is set by a pair of bounds, not by five separate lines. § 3.3.10.108.8smtp-tls-allow-tlsv1.3<domain>Replaced the whole set of five switches: the version range is set by a pair of bounds, not by five separate lines. § 3.3.10.108.9

How to check on the node
Which version was actually negotiated is written to accounting — in the same place as everything else about the message:
pmtaacctfind --output csv[rcpt,dlvTlsProtocol,dlvTlsCipher] /var/log/pmta/acct-*.csv | head -20
Values below the set threshold should not appear. The columns are filled only if dlvTlsProtocol and dlvTlsCipher are named in record-fields — on Hub nodes they are not. If the fields are named and a receiver has an empty field instead of a version, encryption was not established at all — and the threshold may be exactly the reason: log-tls logs the details.
◇

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
reversible: harms only while it is set
Scenarios
Connection encryption
Neighboring settings of the block <domain>:use-starttlsuse-daneuse-mta-stsrequire-starttlssmtp-client-certificateAll 135 directives of the block →