Knowledge base

Refusal at the greeting

EHLO failed
The receiver refuses with words, not with silence

The receiver responded with an error at the very beginning of the session, before the message even came up. Usually this is a temporary refusal: busy, not accepting right now, not allowing the connection.

Its value is that it refuses with words. Unlike silence or a dropped connection, there is response text here — which means there is something to work with: the cause can be understood from it, and a reaction can be configured on it.

This is a textbook reason to slow down. The receiver has said outright that it is struggling right now; continuing at the same speed is a sure way to get a refusal that is no longer temporary.

And this is the refusal it is easiest to set up automation for. A response pattern rule puts the queue into backoff mode (smtp-pattern-list) — that is what the response text is for.

The main trap is retrying at the same speed. A temporary refusal at the greeting is a request to wait. The retry schedule will hear it, but the rate will not: if backoff mode is not configured, the node will keep opening connections at the same frequency, and the receiver will harden its response.
What the Hub does. It reacts from outside — the scheduler sees the growth in refusals in telemetry and slows down by itself.

⚠️ The engine-level reaction is not connected in our setup: there are no response pattern rules in the configuration, so the queue will not go into backoff mode by itself (backoff-mode). The difference is speed: the engine would react right in this connection, the scheduler minutes later.

The response text does reach us: it gets into accounting and is visible in the queue’s refusals.

Recommended values

What to do with such a refusal:

Action When
slow down toward the receiver almost always — that is what it is asking for
create a response pattern rule if the refusals repeat
analyze the response text always: the cause is in it
increase the number of attempts never — the response was about frequency

Read the text, not the code. The same 421 means different things at different receivers, and it is the text that distinguishes them.

Build the rule on the receiver’s words. Codes are generic, words are specific — a rule on the code will catch too much.

The action table and the advice to read the text rather than the code are ours. From the manual here come the cause of the refusal and the fact that it arrives at the first step of the conversation.
Example configuration
# the response text is what makes this refusal valuable
<smtp-pattern-list block-errors>
    reply /^421 .* too many errors/ mode=backoff</smtp-pattern-list>
The highlighted line catches a specific text, not the whole code. A rule on 421 alone would catch both “try again later” and “too many errors” — and those are different events.
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
Troubleshoot deliverability · Tune the pace for a provider