Knowledge base

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

backoff-upon-all-sources-disabled

<domain>

Whether a queue goes into backoff when all its outgoing addresses are disabled
in the configuration this is a linebackoff-upon-all-sources-disabled falseinside the block <domain>
What to do with a queue that has no addresses left

When all of a queue’s sending addresses are disabled, it has nothing to work with. When enabled, the directive puts such a queue into backoff mode instead of letting it keep trying and piling up refusals. The reason for disabling does not matter: a console command and a mailbox provider rule with the disable-source-ip action give the same result.

Why put it there at all. In backoff, separate, lowered limits and a separate retry schedule apply. A queue without addresses will not send anything anyway, but it will stop wasting attempts and spoiling the receiving server’s statistics — and when the addresses come back, the flow will resume without a jolt.

The false default: the queue stays in normal mode and simply stands still.

The main trap, and the vendor itself warns about it. The queue does not come back by itself when an address returns to service: the engine does not link these two events. The manual recommends setting backoff-to-normal-after together with this directive — otherwise the queue will stay in the slowed-down mode even after everything has been fixed. Enabling one without the other is worse than not enabling it at all: sending quietly goes slowly, and the reason is not visible in the configuration.
What the Hub does. It does not write it. It disables addresses with an auto-return and one address at a time, so “all disabled” is not its scenario.

The line is needed where disabling is done by mailbox provider rules: they fire on the receiving server’s reply and may well knock out all of a queue’s addresses in a row if the reply is the same for all of them. It should be set only in a pair with a return timer.

Recommended values

Only together with a return timer. This is not a “just in case” recommendation but a condition for it to work: without backoff-to-normal-after the queue will never leave backoff. A sensible pair is to enable this directive and set a return of several hours.

Leaving it false makes sense if there are no rules with disable-source-ip on the node: the scenario is then unreachable, and an extra line in the configuration only confuses.

Check the queue mode, not this line. It sets a transition, and the result can be seen only in the state of the queues.

From the manual here are the false default, the list of disabling reasons and the vendor’s direct recommendation to set it together with backoff-to-normal-after.
Example configuration
# a pair, not a single line: without the second the queue will not come back
<domain *>
    backoff-upon-all-sources-disabled true    backoff-to-normal-after 4h
</domain>
The second line is required by meaning: the engine does not return the queue to normal mode by itself when the addresses are enabled again.
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 ends3 mistakes▶

Enabling it without a return timer

§ 3.3.10.55

What it costsThe engine does not return the queue to normal mode when an address is enabled again — the manual says so directly. The queue stays in backoff with lowered limits after the cause has gone.
How to spot itThere are no addresses in the disabled list, yet the queue is still in backoff and sending slowly.
How to do it rightSet backoff-to-normal-after in the same block. Switch already stuck queues to normal mode with a separate command.

Enabling it without any rules that disable addresses

our experience

What it costsThe “all addresses disabled” scenario is unreachable if nobody disables them. The line does nothing but looks like working protection — and leads an incident investigation astray.
How to spot itThe directive is enabled, but the disabled list has never had anything in it.
How to do it rightEither remove the line or set up the mailbox provider rules it is meant for.

Looking for the cause of a slowdown in the queue limits

our experience

What it costsIn backoff, not the normal limits apply but separate, lowered ones. The investigation goes into rate settings, while the issue is the queue mode this directive put it into.
How to spot itThe actual rate matches none of the values in the receiver block.
How to do it rightLook at the queue mode first, then at the limits — in backoff a different set of them applies.
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-upon-all-sources-disabled <boolean>
Values
true or false (yes/no are accepted too)
Default
false § 3.3.10.55
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. The change does not affect a queue already in backoff — it will return by its own timer.
How to check on the node
Look at the queue mode, not at the configuration: the line sets a transition, and the state is visible only in the summary.
pmta show queues --maxitems=20
pmta show disabled sources
Compare the two outputs: a queue in backoff with an empty disabled list means the addresses have already come back but the queue has stayed — that is, no return timer is set. The Hub does not write this directive; it picks up queue modes when polling the node.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation · Tune the pace for a provider