Demo
Demo

Knowledge base

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

virtual-mta

<virtual-mta-pool>criticalset by the Hub

A pool member and the share of traffic it gets
in the configuration this is a linevirtual-mtainside the block <virtual-mta-pool>
Who is in the pool and how much each gets

The line is repeated once per member and refers to an already declared sending address — it cannot define one.

The number after the name is a share in percent. The step is a tenth of a percent, and the sum of all shares must be exactly 100. Without numbers the members are used round-robin in equal parts.

Mixing makes no sense: either all members have shares or none do — otherwise the sum of 100 will not add up.

Why a tenth of a percent is needed. The manual’s example — 99.9 versus 0.1 — is putting a new address into service: one message in a thousand leaves from it, the rest from the established one. The same technique works for a canary check of a new node and for a gradual migration.

The main trap. The share is set here, but traffic flows through it only when the pool is chosen. If the sender names a sending address directly — with a header or a pattern rule — the shares play no part at all: the line is there, but there is no distribution.
What the Hub does. It writes it — one line for each sending address of the node in the general submission pool, without shares: a message chosen by neither a header nor a rule leaves round-robin. The Hub does not use shares on purpose: distribution is decided by the warm-up plan, which knows about stages, per-receiver limits and stopping on the spam share. The Hub does not include addresses under warm-up in the backup pool — dumping a flow that the receiving server is already refusing onto an address being warmed up would burn it.
Recommended values

The member name and, optionally, a share. There is one choice here:

Entry Distribution When
virtual-mta mta1 round-robin, evenly the addresses are equal and equally warmed up
virtual-mta mta1 99.9 in the given proportion introducing a new address, a canary, a migration

Recalculate the sum on every edit. The step is a tenth of a percent, so 99.9 and 0.1 add up, while 99.9 and 0.2 no longer do; the error will surface not when the file is edited but when it is applied.

The 0.1% step, the requirement that the sum be 100 and round-robin distribution without shares come from the manual. The comparison with the warm-up plan is ours.
Example configuration
# two pools: one distributes evenly, the other introduces a new address by share
<virtual-mta-pool pool1>
    virtual-mta mta1
    virtual-mta mta2
</virtual-mta-pool>

<virtual-mta-pool pool2>
    virtual-mta mta3 99.9    virtual-mta mta4 0.1
</virtual-mta-pool>
An example from the manual. mta4 will get one message in a thousand — enough for the receiving server to start building a history for the address, and too little to do harm. Both pools refer to sending addresses declared above.
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▶

Setting shares while traffic bypasses the pool

§ 3.3.13.1

What it costsShares apply only to messages that chose the pool. If the sender names a sending address with a header or a pattern rule selects it, distribution plays no part — while the configuration looks set up.
How to spot itIn accounting, one member has the entire volume and the rest have nothing, even though the shares are laid out.
How to do it rightCheck what selects the stream. Distribution by shares makes sense only if submission actually names the pool.

Not recalculating the sum after an edit

§ 3.3.13.1

What it costsThe sum of the shares must be exactly 100. Editing one line breaks the whole definition, and the configuration is not applied.
How to spot itThe reload fails right after a share is changed.
How to do it rightRecalculate on every edit — or assemble the pool with a generator that does the math itself.

Including an address under warm-up in the general pool

our experience

What it costsThe pool is also where everything unselected ends up. An address under warm-up will get a random share of live traffic on top of the plan, and the daily volumes will diverge from the calculation.
How to spot itAn address under warm-up has a volume above plan, and the excess is not explained by the schedule.
How to do it rightKeep addresses under warm-up out of submission pools. The Hub does exactly that — and does not include them in the backup pool either.
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
virtual-mta <name-and-weight>
Values
the name of a declared sending address, optionally a share in percent with a precision of one tenth; the shares must add up to exactly 100
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<virtual-mta-pool>
How many times
may be repeated
Everything here comes from the manual, with the section.
Inheritance
The line itself inherits nothing — it lists. Inheritance goes from the pool to the members: the <domain> block and seven directives written in the pool go to each of them, and a member’s own line overrides the pool one. The same fact implies a ban: a member cannot belong to two pools that have <domain> blocks.
⇄

Related directives

3 relations

Does not work without

The sending address — what it is made ofA member must be a declared sending address — the line only refers to it. § 3.3.13.1

Can be replaced by

Warm-up built into the engineAnother way to give a new address a small share: not a tenth of a percent but the first messages of the day. § 3.3.13.1

Applies to

A group of sending addresses with traffic sharesThe only line a pool consists of; it is repeated once per member. § 3.3.13.1

How to check on the node
The pools’ composition and shares are visible in the node’s list of sending addresses:
pmta show vmtas
Also check that distribution happens at all: if messages choose a sending address by name, they never reach the pool and the shares do not work. This shows in the stream name field in accounting — with working distribution, all members appear there in the given proportion.
◇

What else to read

3 articles

◇A group of sending addresses with traffic sharesA named group of sending addresses; without shares messages are distributed in rotation, with shares in the given proportion, in steps of a tenth of a percent.◇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.◇The sending address — what it is made ofA named set of everything that is a property of the address: which IP the message leaves from, how the node introduces itself, what it signs with and how fast it sends.

In the Hub
Managed at
Infrastructure → Sending addresses
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
disruptive: applying it interrupts the node
Scenarios
Capacity planning · Sending address rotation · Address warm-up
Priority
critical
Neighboring settings of the block <virtual-mta-pool>:domain-keymax-smtp-msg-ratemax-smtp-outsuppression-listsinclude-headers-fromAll 9 directives of the block →