Demo
Demo

Knowledge base

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

data-send-timeout

<domain>

How long to wait for the next piece of the message body to be sent
in the configuration this is a linedata-send-timeout 3minside the block <domain>
While the message body goes out to the network

The conversation has reached the message body. The node sends it in pieces, and this timeout measures the wait for sending one piece — not the whole message and not the receiver’s reply.

It fires where the receiver has stopped reading the incoming stream: the buffer on its side is full, the receive window has closed, the data has nowhere to go. For the node this looks like a hung write to the network.

The lower bound is set by the standard. The manual says plainly: for full compliance with RFC 2821 the timeout must be at least three minutes — exactly what the default is.

The main trap is shortening it together with the others. Conversation timeouts are edited in a batch, and this one gets caught along with connect-timeout and smtp-greeting-timeout. But those have no lower bound, and this one does: by lowering it below three minutes, you go outside the standard — and break transfers to slow receivers where the message would have gone through anyway.
What the Hub does. It does not write it — the vendor 3m stays, and that is the right value: it matches the standard’s lower bound. It is worth touching only upwards and only for heavy messages on slow channels.
Recommended values

Three minutes is a floor, not a recommendation. Less means going outside the mail standard, which the manual warns about separately.

Upwards — for heavy messages. A mailing with attachments to a slow receiver may hit this timeout honestly; five minutes are appropriate there.

Firing is about the receiver, not the message. It means the receiver has stopped taking data from the network, not that the message is too large.

The advice to raise it for heavy messages is ours. From the manual come the 3m default and the direct RFC 2821 requirement to keep it at least three minutes.
Example configuration
# a heavy mailing to a slow receiver — we give some headroom
<domain slow.example.com>
    data-send-timeout 5m</domain>
This timeout is not edited downwards: the three-minute default is the lower bound set by the standard.
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 below three minutes

§ 3.3.10.76

What it costsGoing outside RFC 2821, which the manual warns about separately. Transfers break at slow receivers where the message would have gone through — and every drop carries a risk of a duplicate.
How to spot itTransfer drops at particular domains, while everything is fine for the others.
How to do it rightReturn three minutes and edit only upwards.

Editing it along with the other timeouts

our experience

What it costsThe other conversation timeouts are shortened for speed, and this one gets caught in the same edit. Unlike them, it has a lower bound, and it is violated silently.
How to spot itIn the configuration all timeouts are set to one number.
How to do it rightSeparate them: the waits for connection and greeting may be shortened, the wait for sending the body may not.
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
data-send-timeout <time-interval>
Values
a time interval: a number and a letter — d days, h hours, m minutes, s seconds; at least three minutes per RFC 2821
Default
3m § 3.3.10.76
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 transfers in progress.
⇄

Related directives

2 relations

Works together with

smtp-data-termination-timeout<domain>The next wait: the body has gone out, we wait for acceptance to be confirmed. § 3.3.10.63smtp-greeting-timeout<domain>The previous wait in the same chain, before the conversation reached the message body. § 3.3.10.75

How to check on the node
The effective value is printed by the queue settings command; transfer drops are logged separately if their logging is enabled:
pmta show settings slow.example.com/vmta1 | grep -i data-send-timeout
pmta show settings slow.example.com/vmta1 | grep -i log-transfer-failures
Without transfer drop logging enabled, they are not visible anywhere. The Hub does not set conversation timeouts and does not collect drops.
◇

What else to read

3 articles

◇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.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Reputation monitoring inside the nodeThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Tune the pace for a provider
Neighboring settings of the block <domain>:connect-timeoutauth-usernamecommandallow-cancel-during-transferassume-delivery-upon-data-termination-timeoutAll 135 directives of the block →