Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.19

smtp-server-tls-ciphers

Global

The cipher set on reception for versions up to TLS 1.2
in the configuration this is a linesmtp-server-tls-ciphers HIGH:!ADH:@STRENGTHinside the block Global
What to encrypt incoming connections with — up to version 1.2

The same as the cipher list on sending, only for incoming connections. The notation is that of the OpenSSL ciphers command; the default is HIGH:!ADH:@STRENGTH, that is, strong ciphers, without anonymous ones, sorted by strength.

It applies up to and including TLS 1.2. Version 1.3 has cipher suites arranged differently, and they are set with the smtp-server-tls-v13-ciphersuites line.

The order in the list matters only together with the neighboring line. By default the client chooses a cipher from what we allowed; for the node to choose, smtp-server-tls-cipher-server-preference is needed.

The main trap is narrowing the list and stopping submission. On reception the price of a mistake is higher than on sending: there a message at worst goes out in plain text, here the submitting platform simply will not connect. Check the narrowing before applying it.
What the Hub does. It does not write it — it keeps the vendor default. It already excludes the weak ones, and submission comes from our own platforms, which negotiate modern ciphers without any lists.
Recommended values

The value is a string in OpenSSL notation:

What Note
HIGH:!ADH:@STRENGTH (default) strong ciphers, without anonymous ones, in descending order of strength
your own narrowing check by negotiating with your own platform before applying
version 1.3 not set by this line
preference order taken into account only with the neighbor enabled
The default and the limitation to versions up to 1.2 come from the manual (§ 3.3.1.19). The remark about the price of a mistake on reception is ours.
Example configuration
# the default, written out explicitly
smtp-server-tls-ciphers HIGH:!ADH:@STRENGTH
The manual’s example repeats the default. Narrowing it makes sense only on an external requirement — and after checking that your own platform still connects.
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 the list without checking the submitting platform

our experience

What it costsThe platform stops connecting. Unlike sending, there is no soft degradation here: the connection simply is not established.
How to spot itSubmission stops right after the configuration is applied.
How to do it rightCheck negotiation with the command from the check section before applying. And change the list as a separate step, not together with other edits.
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-ciphers <openssl-cipher-list>
Values
a cipher list string in the notation of the OpenSSL ciphers command
Default
HIGH:!ADH:@STRENGTH § 3.3.1.19
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, in the Global section, and applies to the whole node. An individual listener has its own line — tls-ciphers in <smtp-listener>. Above everything stands openssl-security-level.
How to check on the node
Check by negotiating with the node itself:
openssl s_client -starttls smtp -connect localhost:25 -cipher 'HIGH:!ADH:@STRENGTH'
The line Cipher is … means a common cipher was found. A negotiation error means the list is too narrow, and the submitting platform will not connect either.
In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Connection encryption