Demo
Demo

Knowledge base

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

smtp-tls-v1.3-ciphersuites

<domain>

Cipher set for TLS 1.3
in the configuration this is a linesmtp-tls-v1.3-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256inside the block <domain>
Version 1.3 is configured with its own line

In TLS 1.3 cipher suites are structured differently, and the old line does not apply to them. So they are set with a separate line; the standard defines five of them, and the default lists all.

The default lists five suites — from TLS_AES_256_GCM_SHA384 to TLS_AES_128_CCM_8_SHA256. All of them are modern; there is usually nothing to choose among them.

There is one meaningful reason to narrow: a certification or security policy requirement that lists a specific set. Do not touch it for “hardening”: version 1.3 has no weak suites.

openssl-security-level applies on top of the list — it can forbid even what is allowed here.

The main trap is leaving a single suite. A receiver that does not support it will not negotiate version 1.3 and will fall back to 1.2 — and if it has 1.2 disabled, the connection will not happen at all. In version 1.3 all five suites are strong, and narrowing to one strengthens nothing but only reduces compatibility.
What the Hub does. It does not write it — it leaves the vendor default. All five suites are modern, and there is no reason to choose between them: the difference is in speed on different hardware, not in strength.
Recommended values

The value is a colon-separated list of suites. When it is touched at all:

What When
do not set (default) always
narrow to the list from a policy a certification or client requirement
leave a single suite do not: a receiver without it will fall back to an older version or fail to connect

Check the narrowing by negotiation, as with the ordinary cipher list.

The five-suite default and the separation from the list for versions up to 1.2 are from the manual (§ 3.3.10.108.16). The advice not to narrow to one is ours.
Example configuration
# narrowing to two suites — by policy requirement, not “for hardening”
<domain example.com>
    smtp-tls-v1.3-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256</domain>
The manual’s example. Both suites are strong; the point of the line is compliance with someone’s list, not higher strength.
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▶

Narrowing to one suite “for hardening”

our experience

What it costsStrength does not grow — all five suites are modern — but compatibility drops: a receiver without this suite does not negotiate version 1.3 at all.
How to spot itSome receivers negotiate a lower version than before.
How to do it rightReturn to the default. Narrow only on an external requirement and to at least two suites.
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-v1.3-ciphersuites <string>
Values
a list of TLS 1.3 suites, colon-separated
Default
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256 § 3.3.10.108.16
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. The list for versions up to 1.2 — smtp-tls-ciphers — is set separately and does not affect 1.3.
⇄

Related directives

1 relation

Does not work without

use-starttls<domain>The version 1.3 cipher set is negotiated during encryption and does not apply without it. § 3.3.10.108.16

How to check on the node
Which suite was actually negotiated is visible in accounting next to the version:
pmtaacctfind --output csv[rcpt,dlvTlsProtocol,dlvTlsCipher] /var/log/pmta/acct-*.csv | head -20
Version 1.3 suites are recognized by names starting with TLS_. If the negotiated suite is not in your list, the connection went over an older version — and a different line was in effect. The columns are filled only if dlvTlsProtocol and dlvTlsCipher are named in record-fields; on Hub nodes they are not.
◇

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-mta-stssmtp-tls-min-versionuse-starttlsuse-danerequire-starttlsAll 135 directives of the block →