Demo
Demo

Knowledge base

PMTA knowledge base›Block <virtual-mta-pool>›Directive§ 3.3.13.2

domain

<virtual-mta-pool>

A receiver rules block that goes to all pool members
in the configuration this is a linedomaininside the block <virtual-mta-pool>
The same name 1:<address-list><virtual-mta-pool>— some of them are other settings, some are the same one
Receiver rules written once for the whole group

A regular receiver rules block — rate, streams, retries, TLS — only written in a pool. It goes to each member.

The manual names the inheritance order directly. A receiver block inside a sending address inherits first from the pool, then from the node. That is, there are three levels, and the closer to the message, the stronger: a member’s own block overrides the pool one, the pool one the general one.

And it names the error. A sending address cannot belong to two pools that have such blocks: there would be two sources of inheritance, and nothing to resolve it with. A configuration with such a pair is not allowed.

This block is why a pool is worth creating not only for distribution. A warm-up wave of eight addresses with identical receiver rules is either eight copies that will drift apart over time or one block here.

The main trap is a second pool. The ban fires not where it is created: an address is added to a second pool for distribution, and the whole configuration turns out to be invalid — because of rule blocks written at some point in both. The error will surface on apply and point to the pool that was not touched last.
What the Hub does. It does not write it: it issues receiver rules to each sending address separately and uses a pool only as a list of members. For a warm-up wave this means repeating the same block as many times as there are addresses — more text, more places where values diverge, and a harder-to-read diff between configuration versions. Moving the common rules to the pool level is a clear task for the configurator, and it has to be done together with a “member in only one pool with rules” check.
Recommended values

The block has no values of its own — inside are the same receiver directives as everywhere. Only the level of the entry is decided here:

What we put Where Why
a rule for one receiver for the whole node the node one place, applies to everyone
rules for a warm-up wave or a client the pool a group of addresses lives by the same rules
something of its own for one address the sending address overrides the pool and general ones

And the restriction: a member with such rules can belong only to one pool that has them.

The inheritance order and the ban on two pools come from the manual (§ 3.3.13.2), in direct wording. The breakdown by level is ours.
Example configuration
# a receiver rule set once for the whole warm-up wave
<virtual-mta-pool pool>
    <domain yahoo.com>        max-msg-rate 10/h
    </domain>
    virtual-mta mta1
    virtual-mta mta2
</virtual-mta-pool>
An example from the manual: the yahoo.com/mta1 and yahoo.com/mta2 queues will both get 10/h. Any member’s own <domain yahoo.com> block will override this value.
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▶

Keeping a sending address in two pools with rules

§ 3.3.13.2

What it costsThe whole configuration is invalid. The manual gives exactly this case as a separate example of an “invalid configuration.”
How to spot itThe reload fails and points to the pool that was not edited last.
How to do it rightLeave the member in one pool with rules. What is common to several pools — raise to the node level.

Looking for the cause of a value at the wrong level

§ 3.3.13.2

What it costsThere are three levels, and in the configuration they sit in different places of the file. A value that “did not apply” from the pool is usually overridden by the member’s own block — but it looks like the setting being ignored.
How to spot itThe pool has one value, the member’s queue another, and there are no errors.
How to do it rightLook at the member’s queue, not the configuration: that is where the result is visible. Then look for a block for the same receiver on the sending address itself.
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
domain <block>
Values
a receiver name or pattern, as for a regular rules block
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<virtual-mta-pool>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The pool block is the middle of three levels. A receiver block inside a sending address inherits first from the pool, then from the node; a member’s own line overrides the pool one. Hence the ban on two pools with such blocks: two middle levels for one member cannot be resolved, and the manual calls this an error directly.
⇄

Related directives

3 relations

Same name in other blocks

domain<address-list>A namesake from another block: there the line lists a domain in an address list, here it opens a rules block. § 3.3.5.5

Applies to

A group of sending addresses with traffic sharesThis block is why a pool is a scope and not just a distribution. § 3.3.13.2How the policy for a receiver is assembledThe receiver rules here are the same as everywhere; the only difference is who gets them. § 3.3.13.2

How to check on the node
Merging cannot be read from the configuration — look at the member’s queue:
pmta show queues yahoo.com/mta1
The merged rules apply in the queue. If the pool value is not visible, look for a block for the same receiver on the member itself — it overrides the pool one and does so silently.
◇

What else to read

3 articles

◇A license for a fleet, not for a serverThe license is not bound to a server: it is installed on as many machines as the instance limit allows, and the nodes send volume statistics to the vendor every hour.◇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.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Tune the pace for a provider · Sender isolation
Neighboring settings of the block <virtual-mta-pool>:virtual-mtadomain-keymax-smtp-msg-ratemax-smtp-outsuppression-listsAll 9 directives of the block →