Demo
Demo

Knowledge base

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

tls-cipher-server-preference

<transmissions-api-listener>

Who chooses the cipher on the Transmissions API input — the node or the client
in the configuration this is a linetls-cipher-server-preference falseinside 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
Who has the last word in choosing the cipher

In the handshake the client sends a list of what it supports, and the server chooses. By default the input takes the first suitable one from the client’s list — the client decides. With the value true the order changes: the input goes by its own list and takes the first thing the client supports.

Without this line, sorting your own list is pointless. The @STRENGTH entry in tls-ciphers orders the list by strength, and that order affects nothing while the client chooses.

The setting applies to both versions: both the list up to 1.2 and the tls-v1.3-ciphersuites suites.

The main trap is setting the list and not enabling this line. The work of arranging the order is done, but the decision is still the client’s. The error is silent: submission goes on, just with the wrong cipher.
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

It makes sense only together with your own list:

Value When
false (default) no cipher list was set
true you set your own list and want its order to decide
The false default and the selection rule come from the manual (§ 3.3.21.11). The remark that sorting alone is pointless is ours.
Example configuration
# your own order has force only together with this line
<transmissions-api-listener 1.2.3.4:8585>
    tls-certificate /etc/pmta/transmissions-api-certificate.pem
    tls-ciphers HIGH:!ADH:@STRENGTH
    tls-cipher-server-preference true</transmissions-api-listener>
The two lines work as a pair. Apart, the first sets the list but not the order, and the second insists on the default order.
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▶

Sorting the list and leaving the choice to the client

§ 3.3.21.11

What it costsThe list order is not used. The client takes what suits it — often a faster and less strong cipher.
How to spot itWhat is negotiated is not what comes first in the node’s list.
How to do it rightSet true.

Enabling it without setting your own list

our experience

What it costsThere is insistence, but nothing to insist on: the order comes from the default. The line misleads whoever reads the configuration.
How to spot itThe block has the line, but there is no cipher list next to it.
How to do it rightEither set your own list or remove the line.
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-cipher-server-preference <boolean>
Values
yes | no | true | false
Default
false § 3.3.21.11
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>. Each input has its own decision.
⇄

Related directives

1 relation

Same name in other blocks

tls-cipher-server-preference<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.11

Referenced from

tls-ciphers<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 order here decides the matter only when the server chooses. § 3.3.21.11

How to check on the node
The setting has no direct readout — it is visible from what gets chosen:
openssl s_client -connect NODE:8585 -tls1_2 -brief </dev/null
Compare Ciphersuite: with the start of your list. They match — the node decides; they do not match, and the connection went through — the client decides.
◇

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-ciphersAll 15 directives of the block →