Knowledge base

log-data

<transmissions-api>

Whether to record the content of the exchange during HTTP submission
in the configuration this is a linelog-data falseinside the block <transmissions-api>
The same name 1:<source><transmissions-api>— some of them are other settings, some are the same one
Details of HTTP submission

The line adds to the log the content of the exchange when handling Transmissions API requests. The default is off.

More detailed than log-requests: that line records the fact of a request, this one — what came in it.

🔴 And what comes in a request is the whole message — a JSON body with recipients and content. A log with such entries must be treated as a mail archive and handled accordingly.

The main trap is leaving it on after the investigation. The line breaks nothing and therefore outlives the investigation: the log grows, rotation speeds up, and last week’s entries are pushed out before they are needed.
What the Hub does. It does not write it: our submission goes over SMTP, and there is no API block in the configuration. The line of the same name in <source> is about SMTP submission, and we keep it explicitly off.
Recommended values

Enabled for the duration of an investigation and turned off afterwards:

Value When
no (default) normal operation
yes investigating what exactly the API submitting client sent
The default and the subject of the record come from the manual (§ 3.3.20.3). The order of investigation and the warning about volume are ours.
Example configuration
# for the duration of the investigation
<transmissions-api …>
    log-data true</transmissions-api>
After the investigation the line is removed. With edits through the Hub it will disappear anyway at the next configuration apply.
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▶

Leaving it on after the investigation

our experience

What it costsThe body of every request gets into the log — that is, whole messages, with recipients and content.
How to spot itThe log grows together with the submission flow.
How to do it rightReturn the off value and decide what to do with what has already been recorded.

Looking for these entries in the accounting file

our experience

What it costsThe log and accounting are different files and different questions. Accounting has the result per message, but not the course of the node’s work.
How to spot itThere is nothing resembling the expected entries in the accounting file.
How to do it rightLook at the log whose path is set by the log-file line.
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.20.3
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<transmissions-api>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
No inheritance: the line lives inside its own <transmissions-api> and concerns only it. The log, meanwhile, is one per node — entries from all enabled switches land in it intermixed.
How to check on the node
We look at the engine log, filtering the relevant lines:
grep -i "transmissions\|api" /var/log/pmta/log | tail -20
Entries will appear on calls to the submission API. Nothing means requests do not reach the node at all.
In the Hub
Managed at
Infrastructure → Node parameters
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform