Demo
Demo

Knowledge base

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

disconnect-on-transient-error

<source>

Whether to close the connection instead of a temporary refusal
in the configuration this is a linedisconnect-on-transient-error falseinside the block <source>
A concession to a platform that does not understand 4xx

The default is false. With true the engine closes the connection where it would otherwise respond with a temporary refusal.

The manual names the purpose directly: this helps when the submitting program cannot handle 4xx responses. Such a program usually understands a dropped connection and tries again, while a temporary refusal it may take as final or get stuck in a loop on.

Temporary refusals at acceptance do not come out of nowhere: the node responds with them when it is busy — for example, when it has hit the incoming connection ceiling or the memory limit.

The main trap is that a dropped connection hides the cause. A 4xx response carries text: why it was refused and when to try again. A drop carries nothing. The submitting side sees “connection closed” and does not know whether the node is overloaded, the network blinked or it was rejected.

Investigation becomes more expensive on both sides because of this: your log shows a drop, theirs shows a drop, and they can be linked only by time.

What the Hub does. It does not write it — the vendor false stays. The sending library understands and handles temporary refusals, and a drop instead of a clear response would only muddle the investigation.
Recommended values

What to set. The concession is needed rarely and selectively:

Value When
false (default) the submitting side understands 4xx — the usual case
true an old submission program that breaks or loops on 4xx

The second is worth granting only to the source it was intended for: on a broad block it deprives even those who understood a clear response of it.

The false default and the “submitting program cannot handle 4xx” purpose come from the manual, § 3.3.7.35. The analysis of losing the cause and the advice to grant it selectively are ours.
Example configuration
# a concession to one source, not to the whole node
<source 10.0.0.5>
    disconnect-on-transient-error true</source>
This client will get a dropped connection instead of a 4xx response. Everyone else still gets a clear temporary refusal from the node.
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 on the whole node for the sake of one client

our experience

What it costsAll submitting sides lose a clear response, including those that could read it. Investigating any submission delay becomes more expensive: the logs on both sides show only drops.
How to spot itThe submitting platforms’ logs show dropped connections instead of refusal messages.
How to do it rightGrant the concession to a narrow block — the one where the client that needs it sits.

Taking a drop for a node error

§ 3.3.7.35

What it costsIf the line is enabled, the drop is the node’s response, not a failure. It gets investigated as a network problem and nothing is found, because the problem is in the setting.
How to spot itThe client reports disconnects, while the node’s logs show no errors.
How to do it rightCheck the line in the source block before looking for a network cause.
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
disconnect-on-transient-error <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.35
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 follows source merging: a connection falls under all address blocks that cover it, and a narrow one overrides a broad one. In the 0/0 block the concession goes to everyone — and investigation becomes harder for all submitting sides at once.
⇄

Related directives

1 relation

Works together with

smtp-await-slotGlobalA neighboring decision at the same fork: wait for a slot, refuse temporarily or drop. § 3.3.1.32

How to check on the node
The setting is visible in the configuration; it shows itself only under load:
grep -n 'disconnect-on-transient-error\|total-max-smtp-in\|smtp-await-slot' /etc/pmta/config
The three lines are read together: a temporary refusal arises at the incoming connection ceiling, and this line decides what the client sees instead. Waiting for it to show up without load is pointless.
◇

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-smtputf8max-message-sizeallow-authaccept-invalid-recipientsalways-allow-api-submissionAll 74 directives of the block →