Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.21

smtp-server-tls-cipher-server-preference

Global

Whose preference order rules — the node's or the client's
in the configuration this is a linesmtp-server-tls-cipher-server-preference falseinside the block Global
Who chooses the cipher on an incoming connection

By default, among the ciphers we allow, the client chooses — by its own preference order. The line reverses this: the choice follows our order.

The practical sense is together with @STRENGTH. The manual gives exactly this case: if the list is sorted by strength, the enabled line means “take the strongest one the client understands”. Without it the client may choose a weaker cipher while staying within what is allowed.

The default is false.

The main trap is enabling it without sorting the list. The line makes our order rule, not our assessment of strength. If the list is set arbitrarily, enabling it simply locks in a random choice — and makes it worse than the client’s.
What the Hub does. It does not write it — it keeps the default. Submission comes from our own platforms, and their cipher choice from the allowed set suits us. The line would make sense together with our own cipher list, and the Hub does not write that either.
Recommended values

The value is boolean, and it works only paired with the list:

What is set What you get
default, list at default the client chooses from strong ciphers — usually enough
true, list with @STRENGTH the strongest cipher available to the client is taken
true, unsorted list an order nobody thought through gets locked in
The false default and the example with sorting by strength come from the manual (§ 3.3.1.21). The warning about an unsorted list is ours.
Example configuration
# the order is ours, and it is sorted by strength
smtp-server-tls-ciphers HIGH:!ADH:@STRENGTH
smtp-server-tls-cipher-server-preference true
The lines work only together: the second makes the first one’s order rule. Without @STRENGTH in the list, enabling it locks in an arbitrary 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 ends1 mistake▶

Enabling it without sorting the list

§ 3.3.1.21

What it costsOur order becomes the rule, whatever it is. If the list is not sorted by strength, the node locks in a random choice — possibly weaker than what the client would have chosen.
How to spot itA weaker cipher than expected is negotiated with the line on.
How to do it rightKeep @STRENGTH in the cipher list or do not enable the line at all.
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-cipher-server-preference <boolean>
Values
yes | no | true | false
Default
false § 3.3.1.21
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-cipher-server-preference in <smtp-listener>.
⇄

Related directives

1 relation

Depends on

smtp-server-tls-ciphersGlobalThe order in this list is what becomes the rule when the line is on. § 3.3.1.21

How to check on the node
The difference is visible in the negotiated cipher when connecting with different client preference orders:
openssl s_client -starttls smtp -connect localhost:25 -cipher 'AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384'
With the line on, a stronger cipher is negotiated even if the client put it second. With it off — the first from the client’s list.
◇

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
safe: a wrong value breaks nothing
Scenarios
Connection encryption
Neighboring settings of the block Global:smtp-server-tls-certificateopenssl-security-levelsmtp-server-tls-min-versionhttp-tls-min-versionsmtp-server-tls-ciphersAll 108 directives of the block →