Knowledge base

log-transfer-failures

<domain>set by the Hub

Whether to log breaks during transfer of the message body
in the configuration this is a linelog-transfer-failures falseinside the block <domain>
Where duplicates and truncated messages come from

The line adds to the log connection breaks during transfer of the message headers and body. The default is off.

The vendor names a specific class of faults this line is needed for: duplicates and partial deliveries. The mechanics are as follows: the node transferred the body, the connection broke before confirmation, and the node does not know whether the message arrived. It will retry, and the recipient may see two copies.

This is not visible in accounting. There will be a temporary error or a success, but not “broke off on the body”.

The line is cheap: it writes only on a break, not on every connection.

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 writes it — since Aug 29, 2026, but only in a mailbox provider rule, not in the general recipient block.

Why. With large receivers a break during body transfer has a price: the message may have been accepted, the reply did not arrive, and it goes into a retry — from the outside that is a duplicate. With small domains such breaks usually come from their own servers, and warnings about them would be noise hiding what matters.

What the line does not give. The entry goes to the node log, not to telemetry: the Hub does not see it. It is needed at the moment of investigating “why did the client get the message twice” — then the log has an answer, not emptiness.

Recommended values

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

Value When
no (default) normal operation
yes recipients complain about duplicates or truncated messages
The default and the subject of the record come from the manual (§ 3.3.10.5). The order of investigation and the warning about volume are ours.
Example configuration
# for the duration of the investigation
<domain …>
    log-transfer-failures true</domain>
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▶

Looking for the cause of duplicates in accounting

our experience

What it costsAccounting will show the resend as an ordinary attempt. The fact that the previous one broke off on the body is not there.
How to spot itRecipients see two copies, while in accounting everything looks normal.
How to do it rightEnable this line for the receiver that is being complained about.

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-transfer-failures <boolean>
Values
yes | no | true | false
Default
false § 3.3.10.5
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value is merged across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file — so the line in <domain *> enables logging for all receivers at once. 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 "transfer\|truncat\|abort" /var/log/pmta/log | tail -20
Warnings appear only on breaks. Their absence is a good sign, not a sign that the line is not enabled.
In the Hub
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability