Demo
Demo

Knowledge base

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

smtp-command-timeout

<source>

How long to wait for a command in an incoming SMTP exchange
in the configuration this is a linesmtp-command-timeout 10minside the block <source>
How long to hold a connection that is silent on commands

The default is 10m. The line sets how long the engine waits for the submitting side to send its next command.

This is specifically about the command phase — greeting, sender, recipients. The body transfer phase is covered by the paired smtp-data-timeout.

The split makes sense: a message body can take a long time for objective reasons, while there is usually no reason for the submitting side to be silent between short commands.

The main trap is keeping both limits the same. They share a default, and it is left as is. But the tasks differ: ten minutes to transfer a large message over a slow channel is reasonable, ten minutes between MAIL FROM and RCPT TO is not.

On an open port this is exactly the cheapest way to tie up a receiver: open a connection, say hello and fall silent for ten minutes, occupying a slot from the total-max-smtp-in ceiling.

What the Hub does. It does not write it — the vendor 10m stays, the same as for body transfer.

Meanwhile the submission listener listens to the whole network, and the ceiling of incoming connections is set at 1000. The Hub does not currently try to split the limits.

Recommended values

What to set. The command limit can be noticeably stricter than the body limit:

Value When
10m (default) the port is closed by an address range, only your own submit
1m–2m the port is open to the network: your own platform is not silent that long between commands

The guideline is simple: a command is a short line, and a delay in it means either a fault on the submitting side or not a submission at all.

The 10m default and the purpose (waiting in the command exchange of an incoming connection) come from the manual, § 3.3.7.57. The advice to split the limits is ours.
Example configuration
# there is no reason to be silent for ten minutes between short commands
<source 0/0>
    smtp-data-timeout 3m
    smtp-command-timeout 2m</source>
The pair sets different limits for different phases: the body gets more time, the command exchange less.
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▶

Keeping both limits the same

our experience

What it costsTen minutes of silence between short commands is never legitimate, and the slot is held for nothing. On an open port this is the cheapest way to tie up a receiver.
How to spot itConnections hang for a long time without getting to message transfer.
How to do it rightSplit the limits: more for the body, less for commands.

Setting the limit too strict for the sake of security

our experience

What it costsYour own platform, pausing between commands on a slow network, gets disconnected. The error looks like a network one, and people will look for it in the wrong place.
How to spot itSubmission fails at the command stage, while the channel looks healthy.
How to do it rightMeasure how long the exchange actually takes for your own platform, and take a margin from that number.
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-command-timeout <time-interval>
Values
a time interval, for example 2m or 90s
Default
10m § 3.3.7.57
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 wide block and a generous one in the block of your own submission is the usual layout.
⇄

Related directives

1 relation

Same name in other blocks

smtp-data-timeout<source>The same task for the body transfer phase: this one covers the command exchange, that one — the message itself. § 3.3.7.56

How to check on the node
Both limits are read together with the ceiling of incoming connections:
grep -n 'smtp-command-timeout\|smtp-data-timeout\|total-max-smtp-in' /etc/pmta/config /etc/pmta/virtualhost.txt
Absence of the lines means the vendor ten minutes for both phases. They are worth splitting as soon as the listener is open wider than your own network.
◇

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 →