Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 14

The encryption library is part of the distribution, not the system

bundled tls stack
What the node encrypts with is decided by the distribution, not the server

The daemon uses its own encryption library that came in the distribution. That is why the manual can name its exact version and certificate number, while the system OpenSSL on the same server is a separate program that just has the same name.

The first practical consequence: updating the system changes nothing. Having updated OpenSSL with the package manager, you have changed neither the cipher set nor the available protocol versions. Only a PowerMTA update changes them.

The second: openssl version on the server does not answer about the node. Check what PowerMTA itself shows.

The third: openssl-security-level applies on top of all TLS settings. It forbids whole classes — weak keys, old versions — and does so before the permission in the recipient block even comes into play.

The main trap is fixing encryption at the system level. A scanner report about “an outdated OpenSSL on the server” and the node’s behavior are about different libraries. Updating the system package will not change a single negotiated version, and the time will be wasted.
What the Hub does. It writes no library settings — neither openssl-security-level nor version restrictions. For the fleet this is right: the cipher and version set comes with the PowerMTA version, and that is chosen by the node installation. It is worth remembering during an investigation: if two fleet nodes negotiate different protocol versions with the same configuration, it is the product versions that differ, not the settings.
Recommended values

The mechanism has no values of its own — it is set by the distribution version. What depends on what:

What What determines it
the cipher and version set the PowerMTA version, not the system OpenSSL
allowed key strength openssl-security-level
narrowing the set by certification FIPS mode
the version toward a specific receiver the smtp-tls-min-version and smtp-tls-max-version bounds on top of all this
That the library comes in the distribution and its version is named in the manual is from chapter 14 and chapter 2. The conclusion about scanners and investigating differences between nodes is ours.
Example configuration
# the library security level — for the whole node, on top of all blocks
openssl-security-level 1
# while version bounds are set per receiver
<domain hotmail.com>
    smtp-tls-min-version tlsv1.2
</domain>
The first line can forbid what the second allows: the library level applies earlier and does not depend on recipient blocks. Lower it deliberately — usually for compatibility with an old receiver.
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▶

Updating the system OpenSSL to change the node's encryption

§ 14

What it costsNothing changes: the node uses its own library. The work is done, the report is closed, the behavior is the same.
How to spot itAfter the system update, the negotiated versions and ciphers are the same.
How to do it rightChange the PowerMTA version — that is the only way to update the library. Settings on top of it are set with openssl-security-level and version bounds.

Comparing fleet nodes by configuration rather than by product version

our experience

What it costsThe same configuration on different PowerMTA versions gives a different set of available versions and ciphers. The investigation runs into “but the settings are the same.”
How to spot itOne node negotiates tlsv1.3, another tlsv1.2, with identical recipient blocks.
How to do it rightCompare the product versions. The library comes with the distribution, and a difference in it explains a difference in behavior.
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.
Inheritance
The mechanism has no inheritance: there is one library per process. What is inherited are the settings on top of it — version bounds in <domain> merge by the usual recipient block rule, while openssl-security-level applies to the whole node and has no levels at all.
⇄

Related entries

2 relations

Works together with

What is not allowed in FIPS modeA mode in which the allowed set narrows even further — by certification requirements. § 2.8

Applies to

openssl-security-levelGlobalThe only setting of the built-in library: it allows or forbids whole classes of ciphers and versions. § 2.8

How to check on the node
Ask the node itself, not the system — the libraries are different:
pmta show version
/var/lib/pmta/fips/openssl version
The second line is OpenSSL from the engine’s distribution; the system openssl version answers about a different library. If two fleet nodes negotiate different protocol versions with the same configuration, compare their PowerMTA versions.
◇

What else to read

3 articles

◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Prepare a node for sending · Connection encryption