Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.56

smtp-data-timeout

<source>

How long to wait for data in the message body transfer phase
in the configuration this is a linesmtp-data-timeout 10minside the block <source>
How long to hold a connection that is silent during body transfer

The default is 10m. The line sets how long the engine waits for data from the submitting side in the body transfer phase — after the DATA or BDAT command.

The manual stipulates separately: it applies only to incoming connections. Waiting during delivery is governed by recipient settings.

The paired line is smtp-command-timeout: the same task, but for the command phase, before body transfer.

The main trap is ten minutes per connection. The default is generous, and on a node where a few trusted platforms submit, it does no harm. But every silent connection occupies a slot from the total-max-smtp-in ceiling for all ten minutes — and when the ceiling is exhausted, new ones are refused.

That is, a generous limit turns into a way to tie up the receiver: it is enough to open connections, start a transfer and fall silent.

What the Hub does. It does not write it — the vendor 10m stays.

The ceiling of incoming connections is set, though: total-max-smtp-in 1000 in both configurations, baseline and working. Connections on the submission listener, which listens to the whole network, are held for up to ten minutes of silence each.

Recommended values

What to set. The limit is calculated from who submits:

Value When
10m (default) submission from known platforms in a narrow range
2m–5m the port is open to the network: your own platform is not silent that long, and a stranger will not hold a slot for long

Too strict a limit breaks the transfer of large messages over a slow channel — calculate from the message size and the submitting side’s speed, not from your own impatience.

The 10m default and the caveat “only incoming connections” come from the manual, § 3.3.7.56. The analysis of slot occupation and the breakdown of values are ours.
Example configuration
# the port is open to the network — a silent connection must not hold a slot for ten minutes
<source 0/0>
    smtp-data-timeout 3m    smtp-command-timeout 2m
</source>
Body transfer gets more time than the command exchange: the body travels over the channel, while commands are short lines, and there is no reason to be silent on them for more than a minute.
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▶

Leaving ten minutes on an open port

our experience

What it costsA silent connection holds a slot from the common ceiling for all ten minutes. It is enough to open as many of them as allowed — and the receiver stops accepting mail without actually being busy with anything.
How to spot itThe number of incoming connections is close to the ceiling with a small submission volume.
How to do it rightTighten the limit in the wide source block, keeping a generous one in the block of your own submission.

Expecting the line to affect delivery

§ 3.3.7.56

What it costsIt applies only to incoming connections. Waiting while sending a message to a recipient is set by its settings, and this line does not affect it.
How to spot itThe line is edited because of stuck deliveries, and nothing changes.
How to do it rightLook at the recipient settings: they govern the outgoing side.
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-timeout <time-interval>
Values
a time interval, for example 5m or 90s
Default
10m § 3.3.7.56
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source> and obeys source merging: a connection falls under all address blocks that cover it, and the narrow one overrides the wide one. A strict limit in the 0/0 block and a generous one in the block of your own submission is the usual and correct layout.
⇄

Related directives

1 relation

Same name in other blocks

smtp-command-timeout<source>The same task for the command phase: this one covers body transfer, that one — the exchange before it. § 3.3.7.57

How to check on the node
Both limits are read together with the ceiling of incoming connections:
grep -n 'smtp-data-timeout\|smtp-command-timeout\|total-max-smtp-in' /etc/pmta/config /etc/pmta/virtualhost.txt
pmta show status | grep -i 'smtp-in\|inbound'
Absence of the lines means the vendor ten minutes. Occupied connections are shown by the second command: if their number is close to the ceiling with a small submission volume, the limits are worth tightening.
◇

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 <source>:allow-smtputf8disconnect-on-transient-errorallow-authaccept-invalid-recipientsalways-allow-api-submissionAll 74 directives of the block →