Knowledge base

log-data

<source>set by the Hub

Whether to record every byte of the exchange
in the configuration this is a linelog-data falseinside the block <source>
The same name 1:<source><transmissions-api>— some of them are other settings, some are the same one
The last level, when the others did not help

The line records every byte of the exchange — in two columns at once: hexadecimal codes and their text representation. The default is false.

Why such detail. It answers questions that are not visible in the conversation text: how lines end — with a line feed or with a carriage return and line feed pair, as the standard requires; whether there are non-printable characters in the message; where exactly the transfer breaks off.

The third and last level. log-connections — the fact of a connection, log-commands — the conversation, this one — bytes. Volume grows as a multiple of the message body: the byte-by-byte record is larger than the message itself roughly fourfold.

It must not be enabled under load. This is a tool for a single reproduction of a fault in a narrow source, not an operating mode.

The main trap is enabling it without narrowing the source. On a production flow the byte-by-byte record fills the disk in minutes, and accounting and the spool, which usually live on the same partition, run out of space first.
What the Hub does. It writes it — an explicit no, with the warning “even more verbose!” in the template.

A line of the same name exists in the <transmissions-api> block too — that one is about HTTP submission, and we do not write it: there is no API block in our configuration.

Recommended values

Only for a specific reproduction:

Value When
no (default) always
yes in a narrow source investigating corrupted characters or a transfer break

Before it, go through both lower levels — they are cheaper and most often sufficient.

The false default and the dual form of the record (hexadecimal and text) come from the manual (§ 3.3.7.66). The volume estimate and the rule “lower levels first” are ours.
Example configuration
# the last level: investigating corrupted characters in the message body
<source 10.0.0.7>
    log-data true</source>
The source must be narrow. In 0/0 this line fills the disk in minutes, and accounting on the same partition suffers first.
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 on a production flow

our experience

What it costsThe byte-by-byte record is roughly four times larger than the messages themselves. The disk fills up in minutes, and accounting and the spool on the same partition run out of space first.
How to spot itThe log grew to gigabytes in a matter of minutes.
How to do it rightRemove the line immediately; enable it only in a source limited to one address.
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-data <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.66
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. The same line exists in <transmissions-api> — there it is about HTTP submission.
How to check on the node
The entries are recognizable by the columns of hexadecimal codes:
grep -E "^[0-9A-F]{16,}" /var/log/pmta/log | tail -10
Codes on the left, their text form on the right. This is where you can see how lines end: 0D0A — per the standard, a lone 0A — not.
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