Knowledge base

Three pool rules the manual states directly

VirtualMTA pool behaviour
Distribution, inheritance and a shared name

Chapter 9 adds three facts to the description of a pool, and the middle one settles a question that had to be left open in several places in the analysis of chapter 3.

Distribution is ordinary rotation over the listed members (shares are set separately, with the member line).

Inheritance is stated directly. A recipient block written inside a pool goes to each member; if a member has its own block for the same recipient domain, that one wins. The more specific overrides the more general — one of the few cases where the manual states the resolution order instead of showing it by example.

The namespace is shared — and this follows from a design choice: a pool and a sending address are selected by the same headers, directives and calls. A pool with the name of an existing sending address would be unresolvable, and the engine rejects such a definition rather than parsing it.

The main trap is thinking of a pool only as distribution. It is also a scope: a level between the node and a sending address. Settings shared by a group of addresses — per-receiver limits for a whole warm-up wave — naturally live here, and they are repeated for each member separately only because people do not know about this option.
What the Hub does. It declares a pool but uses only its first half — and even that as a fallback. The second half, the pool as a scope, is not used: the Hub writes receiver rules shared by a warm-up wave for each sending address separately. That means more text in the configuration, more places where values diverge, and a harder-to-read difference when comparing versions.
Recommended values

The mechanism has no values of its own — there are three rules and the question of where to keep what is shared by a group:

What Node level Pool Sending address
a single receiver rule for the whole fleet yes — —
warm-up wave rules — yes repeated for each
address, name, signing key — — yes

The rule is simple: a setting lives at the level where it is decided. Moved lower, it gets repeated and diverges; moved higher, it affects those it should not.

All three rules come from the manual (§ 9.3), including the wording about overriding. The level table is ours.
Example configuration
# a receiver rule set once for the whole group
<virtual-mta-pool warmup-wave-3>
    <domain yahoo.com>        max-msg-rate 10/h
    </domain>
    virtual-mta mta1
    virtual-mta mta2
</virtual-mta-pool>
Both members will get max-msg-rate 10/h for yahoo.com. If mta1 has its own <domain yahoo.com> block, that block wins. The manual’s example with a wave name added.
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▶

Repeating common rules for each member

§ 9.3

What it costsA warm-up wave of eight addresses with identical receiver rules means eight copies of the same thing. Edits do not reach one of them, values diverge, and the difference shows up in behavior rather than when reading the configuration.
How to spot itAddresses of the same wave behave differently at the same receiver.
How to do it rightMove what is shared into a <domain> block inside the pool. Leave the member only what is really its own — address, name, key.

Giving a pool the name of an existing sending address

§ 3.3.13

What it costsSelection uses the same headers, and the collision cannot be resolved. The engine rejects the whole definition — on apply this is a failed reload, not a warning.
How to spot itThe configuration is not applied after a pool is added.
How to do it rightKeep pool and sending address names in one list and check uniqueness before writing the file.
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
There are three levels — node, pool, sending address — and the manual names the order directly: a recipient block inside a sending address inherits first from the pool, then from the node. Hence the prohibition: a member cannot belong to two pools that have <domain> blocks — there would be two sources of inheritance.
How to check on the node
Inheritance cannot be read from the configuration — you have to look at what the member ended up with:
pmta show queues yahoo.com/mta1
The member’s queue applies the merged rules: its own on top of the pool’s on top of the common ones. If the expected value is not visible, look for the member’s own block for the same recipient domain — it overrides the pool one.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Address warm-up · Tune the pace for a provider