Demo
Demo

Knowledge base

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

assume-delivery-upon-data-termination-timeout

<domain>set by the Hub

Whether to consider delivery successful when confirmation never arrived
in the configuration this is a lineassume-delivery-upon-data-termination-timeout falseinside the block <domain>
A bet instead of a retry

The message body has been sent, smtp-data-termination-timeout has expired, and there is no confirmation. From here the node has exactly two paths, and this line chooses between them.

The default false — retry. The node considers the attempt failed and returns the message to the queue. If the receiver actually accepted it, the recipient will see a second copy.

true — record a delivery. There will be no duplicate, but no certainty either: the accounting record will appear regardless of whether the message got through. The manual says so directly — “may result in duplicate messages if used when not needed” — that is, enabling it does not cure anything by itself but shifts the side of the risk.

The main trap is that a delivery record based on a guess is indistinguishable from a real one. In accounting it looks exactly the same, and there is no “we assumed this” marker in it. Deliverability calculated from such accounting is inflated by the entire share of timeouts, and the size of that share can no longer be determined.
What the Hub does. It writes yes — in the recipient policies template, in each of the fifteen blocks: for fourteen major mailbox providers and in the general <domain *>, that is, for all receivers. The reason is given right there in a comment: avoiding repeat delivery.

The cost of this decision is worth knowing. The Hub calculates deliverability from accounting records, and a record made on an assumption counts in that tally on a par with a confirmed one. A duplicate is noticeable to the recipient and causes a complaint; a false delivery is not noticeable at all and quietly inflates the metric.

The trade-off is deliberate: at major mailbox providers a disconnect after the dot is common, and it produces more duplicates than there is inaccuracy in the count. The general block gets the same value, although on your own and small receivers, where disconnects are rare, the false default would be more honest.

Recommended values

Raise the timeout itself first. If confirmations do not arrive, the right answer is to let the receiver finish, not to assign the result for it.

Enable it only for a specific receiver. For a mailbox provider that systematically does not respond after the dot but does accept messages, enabling it is justified. In the wildcard block — never.

Keep in mind that the deliverability metric will become incomparable. It cannot be compared before and after enabling: the numerator is counted differently.

The “timeout first, then this line” order and the warning about the metric becoming incomparable are ours. From the manual here come the false default, the exact trigger condition (the reply to the dot after DATA or to the last BDAT segment) and the caveat about duplicates when used unnecessarily.
Example configuration
# a known receiver is silent after the dot but does accept messages
<domain legacy.example.com>
    smtp-data-termination-timeout 10m
    assume-delivery-upon-data-termination-timeout true</domain>
The line sits next to the full timeout on purpose: enabling it makes sense only when the wait has already been pushed to the limit and did not help.
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▶

Enabling it in the wildcard block

§ 3.3.10.102

What it costsAll confirmation timeouts for all receivers turn into deliveries. The deliverability metric rises, and its connection to reality is lost.
How to spot itDeliverability rose exactly on the day of the configuration edit.
How to do it rightRemove it from the general block; enable it selectively, for a specific receiver.

Enabling it instead of raising the timeout

our experience

What it costsThe cause — an insufficient wait — remains, while its symptom disappears. The receiver still does not manage to respond, but the node no longer notices.
How to spot itIt is enabled with a confirmation timeout noticeably below the default.
How to do it rightFirst return the timeout to ten minutes and see whether the problem remains.
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
assume-delivery-upon-data-termination-timeout <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.102
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 fires only when smtp-data-termination-timeout expires — it does not affect other conversation failures. It is picked up by pmta reload.
⇄

Related directives

2 relations

Depends on

smtp-data-termination-timeout<domain>Fires only when this timeout expires — and changes how it ends. § 3.3.10.102

Affects

Delivered — the record everything is counted byA delivery record made on an assumption is indistinguishable from a real one in accounting. § 3.3.10.102

How to check on the node
The value is printed by the queue settings command; an assumed delivery cannot be told apart from a real one in accounting — all that remains is to compare volumes:
pmta show settings legacy.example.com/vmta1 | grep -i assume-delivery
pmta show queues | grep -i legacy.example.com
A sharp rise in deliverability right after enabling is the only available sign that the share of such records is large. The Hub does not tell them apart.
◇

What else to read

3 articles

◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.

In the Hub
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Bounce classification · Tune the pace for a provider
Neighboring settings of the block <domain>:file-destinationcommandconnect-timeoutallow-cancel-during-transferauth-usernameAll 135 directives of the block →