Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.54

backoff-to-normal-after-delivery

<domain>set by the Hub

Whether one successful delivery returns the queue to normal mode
in the configuration this is a linebackoff-to-normal-after-delivery falseinside the block <domain>
Returning to normal on the first successful delivery

When enabled, one delivery takes the queue out of backoff without waiting for the interval. The logic is simple: the receiver accepted a message — so the cause of the refusals is gone.

It is off by default, like the other exit condition. This leads to the state the manual describes directly: a queue can stay in backoff indefinitely.

The main trap. One delivery is weak evidence. A receiver refusing on reputation often lets some messages through; returning on the first of them restores the full rate at a moment when the problem is not solved. That is why the time condition is still needed — it sets an upper bound.
What the Hub does. It enables it together with the interval. The exit on delivery saves time on short failures, the exit by time insures against a stuck queue.
Recommended values

It is almost always worth enabling. A successful delivery is the most honest sign that the receiving server has stopped objecting. There is no point waiting for a timer after it.

It does not replace backoff-to-normal-after, it complements it. If there are no deliveries at all — and in backoff mode there may be none for a long time — only the timer will bring the queue back. It is sensible to set both.

The false default: the queue waits for the timer even if messages are already going out.

The advice to enable it and set it in a pair is ours. From the manual here are the false default and the fact that the return happens after a successful delivery.
Example configuration
# two ways back: on the first delivery and by time
<domain *>
    backoff-to-normal-after-delivery yes    backoff-to-normal-after 1h
</domain>
Whichever happens first fires. Without the second line, a queue without a single delivery will stay in backoff mode forever.
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▶

Setting only this one, without a timer

our experience

What it costsIf there are no deliveries — and in backoff mode there may be none for a long time — there is nothing to return the queue. It will stay in backoff until at least one message goes through, and with a strict limit that may never happen.
How to spot itThe queue sits in backoff, there are no deliveries, and no timer is set.
How to do it rightSet both: the return on delivery and the return by time.

Waiting for a return while leaving the default

§ 3.3.10.54

What it costsThe false default means the queue does not leave backoff mode even after successful deliveries but waits for the timer. The receiving server is already accepting messages, while the rate stays lowered.
How to spot itAccounting has deliveries for this queue, yet the mode is still backoff.
How to do it rightEnable it: it is the cheapest way not to stay in backoff longer than necessary.
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
backoff-to-normal-after-delivery <boolean>
Values
true or false (yes/no are accepted too)
Default
false § 3.3.10.54
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It is picked up by pmta reload, no restart is needed; for queues already in backoff mode it takes effect immediately.
⇄

Related directives

1 relation

Applies to

Backoff mode — the queue's second personalityThe mode from which the directive returns the queue on the first delivery. § 3.3.10.54

How to check on the node
Checked by behavior: the queue should leave backoff mode after the very first successful delivery, not on a timer.
pmta show settings hotmail.com/vmta1 | grep -i backoff-to-normal-after-delivery
pmta show queues --mode=backoff --maxitems=20
A queue in backoff that has recent deliveries in accounting is a sign that the directive is off. The Hub sets it itself, with the value yes.
◇

What else to read

3 articles

◇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.◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all 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
Managed at
Configurations → Bounce behavior
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation · Tune the pace for a provider
Neighboring settings of the block <domain>:retry-afterbounce-afterbackoff-upon-all-sources-disabledbackoff-retry-afterbackoff-to-normal-afterAll 135 directives of the block →