Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.33

log-tls

<source>

Whether to log the course of TLS negotiation at submission
in the configuration this is a linelog-tls falseinside the block <source>
The same name 2:<domain><source><transmissions-api>— some of them are other settings, some are the same one
Why encryption at submission did not work out

The third place of one and the same switch, and all three are about different conversations: log-tls in <domain> is about outgoing connections to a receiver, this line is about incoming ones, from a submitting platform, and log-tls in <transmissions-api> is about submission over the HTTP API. The default everywhere is false.

This is a diagnostic switch, not a permanent setting. It answers the question “why does the submitting client not encrypt”: STARTTLS was not offered, no common cipher was found, the certificate chain did not match.

Enable it pointwise — for the source in question. The <source> block is set by an address or subnet, and logging can be limited to one submitting platform instead of all.

The main trap is enabling it in the 0/0 source. That is all submitters at once, including the node’s own checks; logging volume will grow by an order of magnitude, and the needed lines will get lost in it.
What the Hub does. It does not write it: it is enabled by hand for the duration of an investigation. The Hub rewrites the configuration entirely at every apply — a line added by hand will disappear at the next apply, and this is exactly the case where that is right.

🔴 There is something to investigate at submission: in the general source we allow unencrypted login and do not require encryption before login, so the submission password may go out in plain text. This line will show whether a specific client came over an encrypted channel.

Recommended values

The value is boolean; the question is where to enable it:

Value When
no (default) always in normal operation
yes in a narrow source investigating one submitting platform
yes in the 0/0 source never
The false default comes from the manual (§ 3.3.7.33). The advice to limit the investigation to one source and the warning about 0/0 are ours.
Example configuration
# investigating one submitting platform, not all at once
<source 10.0.0.7>
    allow-starttls yes
    log-tls true</source>
The source is set narrowly — one address. After the investigation the line is removed: in a general source it gives volume without benefit.
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▶

Enabling it in the 0/0 source

our experience

What it costsEvery connection to submission is logged, including the node’s own checks. Volume grows by an order of magnitude, and the needed lines get lost in it.
How to spot itThe log grows in a jump after the configuration edit.
How to do it rightLimit the block to the address or subnet of the platform under investigation.

Confusing it with the line of the same name in the recipient block

our experience

What it costsThat line is about outgoing connections to a receiver, this one — about incoming ones from a submitter. Enabled in the wrong place, it logs the wrong conversation.
How to spot itThere are entries, but they contain receiver names, not the submitting platform’s address.
How to do it rightFor incoming — <source>, for outgoing — <domain>, for HTTP submission — <transmissions-api>.
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
log-tls <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.33
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source> and goes to whoever’s address matched the block; with several matching blocks, the most exact match wins. The same switch exists separately for outgoing connections — in <domain> — and for submission over the HTTP API.
⇄

Related directives

1 relation

Depends on

allow-starttls<source>There is nothing to log until clients of this source are allowed to start encryption. § 3.3.7.33

How to check on the node
The entries go into the node log; look for them by the submitter’s address:
grep -i "tls" /var/log/pmta/pmta.log | tail -30
You can see whether the client sent STARTTLS, which version and cipher were negotiated, and at which step it broke. Nothing with the line on means the client did not start encryption at all, and the investigation belongs on its side.
◇

What else to read

3 articles

◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇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.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Connect a sending platform
Neighboring settings of the block <source>:log-commandstrace-dkim-checklog-connectionstrace-iprev-checklog-dataAll 74 directives of the block →