Demo
Demo

Knowledge base

PMTA knowledge base›Block <transmissions-api>›Directive§ 3.3.20.2

log-requests

<transmissions-api>

Whether to log calls to the submission API
in the configuration this is a linelog-requests falseinside the block <transmissions-api>
Who submitted messages over HTTP, and when

The line adds calls to the submission API to the log. The default is off.

This is the only trace of HTTP submission. There may be several submission keys (api-key repeats), and without this line it is impossible to answer who exactly submitted and when.

One level lower than log-data: here the fact of a request, there its content.

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 same question for SMTP submission is answered by log-connections and log-commands.
Recommended values

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

Value When
no (default) normal operation
yes a submission key is given to several applications and a trace is needed
The default and the subject of the record come from the manual (§ 3.3.20.2). The order of investigation and the warning about volume are ours.
Example configuration
# for the duration of the investigation
<transmissions-api …>
    log-requests 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▶

Expecting a trace of HTTP submission without this line

our experience

What it costsAccounting will show the accepted messages, but not whose key they were submitted with. There will be nothing to answer “who sent this” with.
How to spot itMessages appeared, the source is unknown.
How to do it rightEnable logging in advance — retroactively it will not help.

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-requests <boolean>
Values
yes | no | true | false
Default
false § 3.3.20.2
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.
⇄

Related directives

1 relation

Applies to

log-fileGlobalThe entries go into the very log set there. inference

Referenced from

log-data<transmissions-api>One level lower: there the fact of a request, here its content. § 3.3.20.3log-tls<transmissions-api>Both write to the engine log: this one about the handshake, that one about the requests themselves. § 3.3.20.2

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
Lines will appear on every request. Their absence while submission works means the line did not apply.
◇

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
reversible: harms only while it is set
Scenarios
Connect a sending platform
Neighboring settings of the block <transmissions-api>:log-datalog-tlsapi-keymax-message-sizeAll 5 directives of the block →