Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 11.18

Spreading a stuck queue across several addresses

rerouting into a pool
Not retreat, but dispersal

An ordinary reroute takes a queue to one address. Here the target is a pool, and messages are spread across its members — as evenly as possible; new messages are distributed the same way while the reroute is in effect.

The intent here is different. Backoff mode is a retreat: send less often, with fewer connections. Rerouting to a pool is dispersal: the same volume, but from several addresses at once. The manual names the goal plainly — to spread the risk of one address being blocked by the receiver.

There are two rules, and both cancel the reroute entirely, not partially. A pool can be only the first link in a chain: a pool met further along the path is ignored. And any path leading into a loop is ignored — not when the configuration is parsed, but silently, at runtime.

The main trap. A pool that is not the first link does not “partially work” — no reroute happens at all. An “address → address → pool” chain leaves messages in the original queue, although each line looks correct on its own. There will be no error: the node will simply do nothing.
What the Hub does. It reroutes to a single reserve address, not to a pool: in backoff mode it writes backoff-reroute-to-virtual-mta with the name of a specific address. Dispersal across a pool is the next step, and it requires the infrastructure to have several equivalent addresses for one receiver.
Recommended values

The mechanism has no values of its own — they are set by the reroute directive. One thing is decided here: where to take the queue.

Where What you get When
one sending address the whole rejected queue on one address the address is known to be healthy and will cope
a pool the load is spread among the members there are several addresses and all are warmed up
nowhere the queue stays on the same address and lowers its rate there is no spare address

Addresses under warm-up are not included in such a pool. Dumping onto a new address a flow the receiver is already refusing means burning its reputation before it takes shape.

The ability to name a pool instead of an address comes from the manual. The ban on including warming addresses in such a pool is our rule, from how warm-up works in the Hub.
Example configuration
# rerouting to a pool: messages will be split between vmta2 and vmta3
<virtual-mta vmta1>
    <domain aol.com>
        reroute-to-virtual-mta pool    </domain>
</virtual-mta>

<virtual-mta-pool pool>
    virtual-mta vmta2
    virtual-mta vmta3
</virtual-mta-pool>
Member shares can be set as numbers, but the manual explicitly advises against fractional ones — such as 99.9 and 0.1: at that granularity distribution starts costing performance. Whole numbers are safer.
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▶

Placing the pool not as the first link in the chain

§ 11.18.2

What it costsNo reroute happens at all — not partially, but entirely. Messages stay in the original queue, although each line of the chain looks correct.
How to spot itA reroute chain is set, messages stay put.
How to do it rightMake the pool the first reroute target from the original queue, not a link in the middle.

Setting member shares to tenths

§ 11.18.1

What it costsThe manual warns: a 0.1% step noticeably affects distribution performance. The gain in precision is illusory — volumes fluctuate more anyway.
How to spot itWith pool distribution enabled, node load grows without growth in sending.
How to do it rightUse whole shares — 99 and 1, not 99.9 and 0.1.
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.
Inheritance
The mechanism has no inheritance — the reroute directive is what is inherited: it lives in the receiver block and merges by the usual rule, where a narrower block overrides a wider one. The pool itself adds no inheritance: it only names whom to share the rerouted queue among.
⇄

Related entries

2 relations

Does not work without

A group of sending addresses with traffic sharesThe pool among whose members messages are spread. § 11.18.1

Applies to

Reputation monitoring inside the nodeRerouting is the strongest reaction to worsening reputation; this form of it changes its meaning from retreat to dispersal. § 11.18.1

Referenced from

reroute-to-virtual-mta<domain>The pool form of this same line, with its own two rules — about chains and about loops. § 11.18

How to check on the node
Distribution is visible in the queue list: the original pair empties, and messages appear at several addresses for the same receiver at once:
pmta show queues | grep -i aol.com
pmta show settings aol.com/vmta1 | grep -i reroute
If messages stayed in the original queue — either the pool is not the first link, or the chain has a loop: both cancel the reroute silently. The Hub does not use rerouting to a pool yet.
◇

What else to read

3 articles

◇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.◇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.◇Warm-up built into the engineA warmed-up address hands the first N messages of the day for each receiver to its cold partner; the partner sends them itself and builds history.

In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Sending address rotation