Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.20

smtp-server-tls-v1.3-ciphersuites

Global

Cipher set for receiving over TLS 1.3
in the configuration this is a linesmtp-server-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 Global
Version 1.3 for receiving is configured with its own line

The same as the list of 1.3 suites for sending, only for incoming connections. The default lists five suites — from TLS_AES_256_GCM_SHA384 to TLS_AES_128_CCM_8_SHA256.

All five are modern, and there is usually nothing to choose between them: the difference is in speed on different hardware, not in strength.

A meaningful reason to narrow is an external requirement with a specific list. Do not touch it for “hardening”: version 1.3 has no weak suites.

The main trap is leaving a single suite. A submitting platform without it will not negotiate version 1.3 at all, and with a raised floor it will not connect at all. Narrowing to one suite strengthens nothing.
What the Hub does. It does not write it — it leaves the vendor default. All five suites are modern, and submission from our own platforms negotiates without any configuration.
Recommended values

The value is a colon-separated list of suites:

What When
do not set (default) always
narrow to the list from a policy an external requirement
leave a single suite do not: submission may not come up at all
The five-suite default is from the manual (§ 3.3.1.20). The advice not to narrow to one is ours.
Example configuration
# narrowing to two — by policy requirement, not “for hardening”
smtp-server-tls-v1.3-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
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 a submitting platform without this suite will not negotiate version 1.3.
How to spot itSubmission goes over a lower version than before, or stops.
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-server-tls-v1.3-ciphersuites <openssl-ciphersuite-list>
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.1.20
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 line — tls-v1.3-ciphersuites in <smtp-listener>. The list for versions up to 1.2 is set separately and does not affect 1.3.
⇄

Related directives

1 relation

Works together with

smtp-server-tls-ciphersGlobalThe list for versions up to 1.2; version 1.3 suites are structured differently and are set here. § 3.3.1.20

How to check on the node
It is checked by negotiating over version 1.3:
openssl s_client -starttls smtp -connect localhost:25 -tls1_3
The response shows the negotiated suite — it starts with TLS_. If the connection does not come up at all, the list has been narrowed too much.
◇

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
dangerous: effects outlast a rollback
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 →