Knowledge base

The receiver went silent mid-conversation

ETIMEDOUT
Ten minutes of silence — and they are not configurable

The connection was established, the conversation began — and the receiver went silent. The manual names two causes: it is overloaded or there are connectivity problems.

🔴 The wait lasts ten minutes, and it cannot be configured. In a product with hundreds of configurable directives this is rare, and it matters: each stalled attempt occupies a slot in the connection count for ten minutes.

Hence a consequence about cost. A receiver that is silent is more expensive than a receiver that refuses: a refusal frees the connection right away, silence holds it for ten minutes. On a node with a limited number of outgoing connections, one such receiver can take up a noticeable share of them.

The main trap is looking for a setting for this time. There is none. The only way to reduce the damage is to limit how many connections go to the problematic receiver at all: the connection ceiling in its receiver block is exactly the lever that fixes this.
What the Hub does. It does not distinguish this failure separately — it lands in the general transport failure category.

⚠️ Yet it is the most expensive one: a silent receiver holds connections for ten minutes each. It can be noticed on our charts indirectly — the failure rate is low, while the number of open connections hits the ceiling.

It is fixed by limiting connections to the problematic receiver — and the Hub can make such an edit once the decision is made.

Recommended values

What to do about it:

Action Helps
lower the connection ceiling for this receiver yes — it limits the losses
shorten the wait time impossible, it is not configurable
raise the overall connection ceiling no, a silent receiver will eat that too

The sign in numbers: many connections are open, few messages go out, there are almost no refusals. Ordinary overload looks different — there the refusal rate grows.

The analysis of connection cost and the sign in numbers are ours. From the manual here come the cause of the failure and the fact that the ten-minute wait is not configurable.
Example configuration
# the only lever against a silent receiver
<domain slow.example.com>
    max-smtp-out 2</domain>
The highlighted line limits the number of connections to the problematic receiver. The wait time itself is not configurable, so what is reduced is not the time but the number of attempts that can get stuck in it.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Tune the pace for a provider · Untangle a stuck queue