Demo
Demo

Knowledge base

PMTA knowledge base›Error code§ 5.8

The receiver refused the connection

ECONNREFUSED
Two causes that lead to opposite actions

The connection was not established at all — the host rejected it right away. The manual gives two readings, and they call for opposite actions.

The first: the receiver’s server is temporarily down or not working. This is a temporary problem, it will pass by itself, and retries exist precisely for it.

The second: a network filter is rejecting connections from us specifically. This will never pass by itself: as long as the sending address is on someone’s list, every attempt will be rejected.

The two cannot be told apart by the refusal itself — it is the same. What distinguishes them is comparison: if one sending address gets the refusal and another does not for the same receiver, the problem is the address, not the receiver.

The main trap is waiting for it to pass by itself. Retries make sense only under the first reading. If the sending address is blocked, every single retry will be rejected, and the queue will grow until the bounce deadline — and for that whole period the node will waste attempts.
What the Hub does. It distinguishes them indirectly: comparing one receiver across different sending addresses is exactly the way an address block is separated from a problem at the receiver.

The per-provider view shows the receiver as a whole, the per-queue view shows the pair (queue-identity). A divergence between them is the signal: if the refusal is visible for only one address, the problem is the address.

⚠️ We have no separate “we are blocked” indicator — the conclusion is drawn by eye from the two views.

Recommended values

How to tell the two readings apart:

Observation Reading
refusal for all sending addresses the receiver’s server is not working — wait
refusal for one address, not for others the address is blocked — waiting is pointless
the refusal appeared after the rate went up receiver protection — slow down and wait

A blocked address is not cured by retries. It is cured by contacting the receiver, changing the address or pausing — but not by the node trying again.

Check by comparison, not by guesswork. The same receiver from two addresses is the fastest answer.

The distinction table and the conclusion that retries are useless are ours. From the manual here come both readings of the refusal.
Example configuration
# it tells apart not the refusal but the address comparison
pmta show queues --errors example.compmta show settings example.com/mta-news-1
The highlighted line shows the refusals for each queue of this receiver. If one pair has the refusal and the others do not, the problem is the sending address, not the receiver.
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

2 relations

Depends on

A queue is a receiving server together with a sending addressComparing one receiver across different addresses is what separates an address block from a problem at the receiver. inference

Can be replaced by

The receiver went silent mid-conversationA neighboring failure: there the receiver is silent, here it rejects right away — and the latter is cheaper. § 5.8

Referenced from

Take one address out of service for one queueA persistent refusal of one address by one receiving server is a typical reason to take the address out of service. inferenceTemporary queue failureConnection-level refusals are recorded exactly here. inference

◇

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.◇What makes a virtual machine riskyRunning on a virtual machine is possible, but the manual does not recommend it without sufficient hardware and properly tuned hypervisor settings: under load the node may stop responding.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Untangle a stuck queue