Demo
Demo

Knowledge base

PMTA knowledge base›Error code§ 5.8

The receiver dropped the connection

EDISCON
The second cause is more interesting than the first

The connection was broken from the receiver’s side. The manual names two causes, and the second is far more telling.

The first — the server was shut down or crashed. An ordinary fault that passes by itself.

The second — the receiver closed the connection in response to the message content. This is an extreme measure: instead of refusing in words, it simply leaves. Filters behave this way when they have nothing to explain or no reason to.

Selectiveness helps tell them apart. Drops on all messages in a row are about the server. Drops on some messages while the rest are delivered normally are about the content.

The main trap is always treating a drop as a network problem. The investigation goes into the network and connection settings, while the cause may be in the message. The sign is simple: if connections drop only for one mailing and the others go through, the network has nothing to do with it.
What the Hub does. It does not tell it apart separately — the drop ends up among transport failures.

⚠️ And this is exactly the case where the category misleads: a drop caused by content looks like a network fault but is fixed by editing the message.

We do have an indirect sign: if drops cluster around one mailing while the others go normally, the problem is in its content.

Recommended values

How to tell them apart:

Observation Cause
all connections to the receiver drop the server is off or has crashed
a part tied to one mailing drops the message content
drops began after a template change almost certainly the content

Look for content problems not in the network but in the message. Links, attachments, domains in the text — what a filter looks at.

Talking to the receiver will not help: it said nothing, and there is nothing to explain to it.

The distinguishing table and the advice to look in the message are ours. From the manual come both causes of a drop, including the response to content.
Example configuration
# the sign is selectivity, not the disconnect itself
pmta show queues --errors example.com
The highlighted line shows the queue’s recent errors. If the drops fall on messages of one mailing while the others go out, the cause is in the content, not in the network.
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.
⇄

Related entries

1 relation

Works together with

Refusal at the greetingA neighboring failure: there the receiver explains itself in words, here it simply leaves. § 5.8

◇

What else to read

3 articles

◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇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.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability