Demo
Demo

Knowledge base

PMTA knowledge base›Block <transmissions-api-listener>›Directive§ 3.3.21.9

tls-ciphers

<transmissions-api-listener>

The Transmissions API input cipher set for versions up to TLS 1.2
in the configuration this is a linetls-ciphers HIGH:!ADH:@STRENGTHinside the block <transmissions-api-listener>
The same name 1:<smtp-listener><transmissions-api-listener>— some of them are other settings, some are the same one
Ciphers of the second submission method

The list of allowed ciphers for connections of this input. The notation is that of the OpenSSL ciphers command, default HIGH:!ADH:@STRENGTH: only strong suites, without anonymous key exchange, sorted by strength.

It applies up to and including TLS 1.2. Version 1.3 has its own list — tls-v1.3-ciphersuites.

The order matters only together with tls-cipher-server-preference: by default the client chooses the cipher, and @STRENGTH sorting affects nothing.

The main trap is narrowing the list and losing submission. A client that finds no common cipher will not connect, and messages will stop reaching the engine altogether. Unlike sending, where a message at worst goes out in plain text, here the price of a mistake is stopped submission.
What the Hub does. It does not write it: our submission goes over SMTP, and there is no API entry point block in the configuration.
Recommended values

The default is sensible; change it only on an external requirement:

Value When
HIGH:!ADH:@STRENGTH (default) always
your own narrowing an audit requirement, with submission checked before applying
version 1.3 not set by this line
The default and the limitation to versions up to 1.2 come from the manual (§ 3.3.21.9). The remark about stopped submission is ours.
Example configuration
# the default, written out explicitly
<transmissions-api-listener 1.2.3.4:8585>
    tls-certificate /etc/pmta/transmissions-api-certificate.pem
    tls-ciphers HIGH:!ADH:@STRENGTH</transmissions-api-listener>
The manual’s example. Narrowing makes sense only on an external requirement and after checking that the submitting client 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 ends2 mistakes▶

Narrowing the list without checking the submitting client

our experience

What it costsSubmission stops entirely: the client has nothing to agree on, and messages do not reach the engine. This is noticeable not from the sending log but from its absence.
How to spot itThe queue is empty, while the submitting platform accumulates connection errors.
How to do it rightReturn the default, test the narrowing on one client, and only then roll it out to all nodes.

Setting version 1.3 ciphers with this line

§ 3.3.21.10

What it costsThe list applies up to and including 1.2. The names of 1.3 suites mean nothing in it, and the needed ones remain at the default.
How to spot itThe list is set, but on 1.3 a suite not from it is negotiated.
How to do it rightWrite 1.3 suites into tls-v1.3-ciphersuites.
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
tls-ciphers <string>
Values
a cipher list string in the notation of the OpenSSL ciphers command
Default
HIGH:!ADH:@STRENGTH § 3.3.21.9
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<transmissions-api-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
No inheritance: the line applies inside its own <transmissions-api-listener>. The mail lists — smtp-server-tls-ciphers on reception and smtp-tls-ciphers on sending — have nothing to do with this input.
⇄

Related directives

3 relations

Same name in other blocks

tls-ciphers<smtp-listener>The same-named line of the mail listener; here it is about a separate entry point, the API’s own. § 3.3.21.9

Works together with

tls-cipher-server-preference<transmissions-api-listener>The order in this list decides the matter only when the server chooses. § 3.3.21.11tls-v1.3-ciphersuites<transmissions-api-listener>The two lists split the work by protocol version: this one ends at TLS 1.2. § 3.3.21.10

How to check on the node
We look at which cipher was actually negotiated:
openssl s_client -connect NODE:8585 -tls1_2 -brief </dev/null
The line Ciphersuite: shows the chosen suite. A negotiation error instead of it means the list is too narrow for the submitting client.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security
Neighboring settings of the block <transmissions-api-listener>:tls-min-versiontls-certificatetls-max-versiontls-ca-filetls-cipher-server-preferenceAll 15 directives of the block →