Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.63

smtp-data-termination-timeout

<domain>

How long to wait for the final 250 after sending the message body
in the configuration this is a linesmtp-data-termination-timeout 10minside the block <domain>
The message is sent, there is no answer

The message body has been sent in full, the dot is in place. The receiver has to answer 250 ok — that is, confirm the message was accepted. This wait is what this timeout measures.

This is the most ambiguous moment of the conversation. Until there is an answer, the node does not know whether the message was accepted. The receiver may have accepted it and not had time to answer; may not have accepted it; may have hung on an antivirus scan. The mail protocol does not make this distinction.

Hence the manual’s direct warning: a value that is too small will most likely lead to duplicates. The node will decide the delivery did not happen and retry the message — while the receiver has already accepted it.

The main trap is shortening it “so it does not hang.” The ten-minute default seems like an eternity while the queue stands still. But this is exactly where a long wait is cheaper than a short one: a minute saved per message versus a second copy at the recipient. After the dot, large receivers go off to scan the content, and an answer taking several minutes is normal behavior for them.
What the Hub does. It does not write it — the vendor’s 10m remains, and that is the right value. The only direction in which it would be worth touching is down, and that is exactly what should not be done.
Recommended values

Keep the default. Of all the conversation timeouts, this is the only one where shortening costs more than waiting.

If the queue is stalled, this is not the cause. A long wait for the final answer occupies a connection slot, but that is cured with the max-smtp-out ceiling, not by shortening the timeout.

Do not shorten it to speed things up after a failure. For a queue the receiver is slowing down, the answer is supposed to come slowly — that is its way of slowing you down.

The “do not shorten” rule and the advice to cure the queue with the connection ceiling are ours. From the manual here come the 10m default and the direct warning: a value that is too small will most likely lead to duplicates.
Example configuration
# the default is kept deliberately; the queue is managed by connections, not by the timeout
<domain gmail.com>
    smtp-data-termination-timeout 10m    max-smtp-out 20
</domain>
The line is written explicitly not to change the value but so that nobody shortens it during the next timeout edit: the real cure for a stalled queue sits right next to it.
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▶

Shortening it so the queue does not stall

§ 3.3.10.63

What it costsThe node stops waiting for confirmation and retries messages the receiver has already accepted. The recipient sees a second copy, and sometimes a third — the manual warns about this directly.
How to spot itComplaints about repeated messages, while there are no bounces in accounting.
How to do it rightRestore the default and manage the queue with the max-smtp-out ceiling.

Treating a slow answer as a receiver malfunction

our experience

What it costsAfter the dot, large receivers go off to scan the content, and an answer taking several minutes is normal for them. Shortening the timeout for them breaks delivery exactly where it used to work.
How to spot itDuplicates appeared at one large mailbox provider, while everything is the same at the others.
How to do it rightTell a slow answer apart from no answer: the first is normal.
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
smtp-data-termination-timeout <time-interval>
Values
a time interval: a number and a letter — d days, h hours, m minutes, s seconds
Default
10m § 3.3.10.63
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 merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It is picked up by pmta reload; it does not affect conversations in progress.
How to check on the node
The effective value is printed by the queue settings command; complaints about duplicates are the only outward sign that it is set too low:
pmta show settings gmail.com/vmta1 | grep -i data-termination-timeout
pmta show queues --connected=yes --no-rcpt-events
The timeout itself is not visible in accounting: when it fires it produces a transient failure indistinguishable from the others. The Hub does not track duplicates — people learn about them from recipients.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Tune the pace for a provider