Knowledge base

log-connections

<source>set by the Hub

Whether to record the start and end of every connection
in the configuration this is a linelog-connections falseinside the block <source>
The first level of log detail

The line adds a log entry at the start and at the end of every connection from the source. The default is false.

This is the cheapest of the three levels of detail. In ascending order: this line — the fact of a connection; log-commands — the whole SMTP conversation; log-data — every byte in two forms. Volume grows by an order of magnitude with each level.

It answers one question: does the submitter reach us at all. When a platform says “cannot send” and accounting is empty, this line tells two cases apart: the connection is not established — investigate the network and the source list; it is established and closed right away — the problem is in the submission.

The line is about incoming connections, because it lives in the source block. Outgoing connections to receivers are not logged by this line.

The main trap is enabling it in the 0/0 source. That is all submitters at once, including the node’s own checks and anyone who just knocked on the port. Volume grows unpredictably, and the needed entries get lost in it.
What the Hub does. It writes it — an explicit no in the source block, together with log-commands and log-data.

Writing the default explicitly makes sense here: three lines in a row show whoever reads the configuration that the levels of detail are known and turned off deliberately, not forgotten. Next to them the template has the warnings “verbose” and “even more verbose”.

Recommended values

Enabled pointwise and temporarily:

Value When
no (default) normal operation
yes in a narrow source investigating one submitting platform
yes in 0/0 almost never
The false default and the fact that entries are made at the start and at the end of a connection come from the manual (§ 3.3.7.64). The ladder of three levels of detail and the warning about 0/0 are ours.
Example configuration
# investigating one submitting platform, not all at once
<source 10.0.0.7>
    log-connections yes</source>
The source is set narrowly — one address. In 0/0 the same line records every touch of the port, including other people’s scanners.
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 in the 0/0 source and drowning in entries

our experience

What it costsEvery touch of the port is recorded, including scanners and the node’s own checks. The log grows, rotation speeds up, and the needed entries get pushed out.
How to spot itThe log jumped in size right after the configuration edit.
How to do it rightLimit the block to the address of the platform under investigation.
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-connections <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.64
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. This line does not log connections to receivers.
How to check on the node
We watch the log and make one connection to the submission port:
tail -f /var/log/pmta/log
Two lines will appear — open and close. Nothing means the connection did not reach the node: look at the network and smtp-listener.
In the Hub
Managed at
Infrastructure → Node parameters
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Untangle a stuck queue