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 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.
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 response text is what makes this refusal valuable <smtp-pattern-list block-errors> reply /^421 .* too many errors/ mode=backoff</smtp-pattern-list>
2 relations
Three short histories for each queueOne of the refusals that end up in the second buffer — queue errors. § 5.8The receiver dropped the connectionA neighboring failure: there the receiver explains itself in words, here it simply leaves. § 5.8Removing a sending address — and what happens to its queueUnlike a refusal from the receiving server, this bounce originates on our node and says nothing about the recipient. inference
3 articles
◇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.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Reputation monitoring inside the nodeThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.