Demo
Demo

Knowledge base

PMTA knowledge base›Block <smtp-listener>›Directive§ 3.3.17.15

tls-ca-file

<smtp-listener>

Trusted authorities for this listener's clients
in the configuration this is a linetls-ca-fileinside the block <smtp-listener>
The same name 2:<smtp-listener><smtp-user><transmissions-api-listener>— some of them are other settings, some are the same one
Whom to trust on this input

The line names the file with root certificates against which the certificates of clients coming to this input are verified.

It is inherited from smtp-server-tls-ca-file — not set here, the node’s list applies.

By itself it requires nothing. It names whom to trust; the requirement to present a certificate is set by the login verification method — authentication-method in <smtp-user>.

The main trap is believing the line enables mutual verification. It does not. Without a login verification method that requires a certificate, the list takes part in no connection.
What the Hub does. It does not write it: submission goes by login and password or from allowed addresses, there are no client certificates. The line will be needed together with the ca-file verification method — and they have to be configured as a pair.
Recommended values

The file is set for the listener separately — the manual does not promise inheritance from the node:

What When
do not set clients on this input are not verified
file clients of this input are verified by certificate — even if the same file is set on the node
Inheritance from the node’s list comes from the manual (§ 3.3.17.15). The remark that the line requires nothing is ours.
Example configuration
# setting for one input, the others take the node's value
<smtp-listener 10.0.0.1:2525>
    tls-ca-file /etc/pmta/partner-ca.pem</smtp-listener>
A separate input for partner submission with its own circle of trust. Verification is enabled not here but by the login verification method.
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▶

Configuring the listener instead of the node when there is only one entry point

§ 3.3.17.15

What it costsThere is one listener, and configuring it is equivalent to configuring the node — but it is harder to find: it sits inside a block, not at the root of the file. The next person will look in the common settings.
How to spot itThe setting is not at the root of the file, yet the node’s behavior does not match it.
How to do it rightWith one entry point, set it at the node level. A listener setting is needed where there are several entry points and they differ.

Changing one listener and expecting all of them to change

our experience

What it costsThe line applies only to its own address and port. A neighboring entry point keeps working with the node value, and the difference shows up in the behavior of different clients.
How to spot itSome submitters see the new behavior, others the old one.
How to do it rightChange it at the node level — then the change goes to all entry points that do not set their own.
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-ca-file <path>
Values
path to a file with root certificates in PEM format
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<smtp-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <smtp-listener> and applies to connections on its address and port. The manual does not promise inheritance from smtp-server-tls-ca-file: “inherited from the node” is said only about tls-certificate. If clients on this input need verification, set the file here explicitly.
⇄

Related directives

1 relation

Applies to

smtp-listenerGlobalThe line lives inside a listener and applies to connections to its address and port. § 3.3.17.15

Referenced from

tls-ca-file<transmissions-api-listener>The same-named line of the mail listener; here it is about a separate entry point, the API’s own. § 3.3.21.12

How to check on the node
Check the port of the listener in question — a neighboring one may have a different value:
openssl crl2pkcs7 -nocrl -certfile /etc/pmta/partner-ca.pem | openssl pkcs7 -print_certs -noout
The output lists the subjects of the certificates in the file. If verification does not trigger, look for the login verification method: without it the list takes no part.
◇

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.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.◇The load balancer header at the entranceThe node reads the PROXY header at the start of an incoming connection and treats the address from it as the source; this works for both kinds of entry point.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Connect a sending platform
Neighboring settings of the block <smtp-listener>:tls-certificatetls-min-versionimmediate-tlstls-v1.3-ciphersuitestls-cipher-server-preferenceAll 18 directives of the block →