Knowledge base

cold-virtual-mta

<virtual-mta>

The partner this address hands the first messages of the day to
in the configuration this is a linecold-virtual-mtainside the block <virtual-mta>
Whom to hand messages to while a new address builds history

The line names a partner — another sending address that will get the first messages of the day to each receiver. How many exactly is not set here: that is a separate max-cold-virtual-mta-msg directive in the receiver block.

Both halves are required. A quota without a partner does nothing — the manual says so directly; a partner without a quota does nothing either, because the quota defaults to 0/d.

It can be repeated. Then the partners are used in rotation, and the quota applies to each of them separately: two partners with 100/d mean two hundred messages per receiver, not a hundred shared.

The partner is an ordinary sending address and must be declared with its own block. It delivers messages by its own settings and inherits nothing from the one that handed them over.

The main trap. The line looks self-sufficient — you named a partner, and warm-up is under way. In fact without max-cold-virtual-mta-msg it does nothing: the default quota is zero, and a zero quota means “do not select the partner.”
What the Hub does. It does not write it: warm-up in the Hub is driven by the plan, not by the engine. The line is still useful as an alternative for nodes warmed up outside the Hub — and as a clear hybrid form: the Hub decides the daily number, the engine carries out the split of the flow.
Recommended values

The value is the name of a declared sending address. What is decided along with it:

How many partners What you get
one all cold traffic goes to one address — the usual case
several partners in rotation, and the quota counts for each
none the quota, even if set, does nothing

Whom to assign as the partner. The address you are putting into service — with a fully filled-in block: its own source, its own name, its own signing key, its own limits.

The second half being required and the 0/d default come from the manual. The remark about the quota being counted for each partner comes from § 3.3.10.57; the “whom to assign” analysis is ours.
Example configuration
# the warmed-up address names the partner and the daily quota
<virtual-mta vmta1>
    smtp-source-host 1.2.3.4 vmta1.example.com
    cold-virtual-mta vmta2    <domain *>
        max-cold-virtual-mta-msg 1/day,2/day,5/day,10/day
    </domain>
</virtual-mta>
The quota is set as a ladder: 1, 2, 5, 10 messages per receiver, then 10 daily. The partner vmta2 itself must be declared in a separate block with its own settings — it inherits nothing.
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▶

Naming a partner and expecting that to be enough

§ 11.6

What it costsThe quota defaults to 0/d, that is, “do not select the partner.” The line is in the configuration, applies without errors and does nothing.
How to spot itThe partner’s name never appears in accounting.
How to do it rightSet max-cold-virtual-mta-msg in the receiver block of the same sending address. It is one setting made of two lines.

Setting several partners, assuming the quota is shared

§ 3.3.10.57

What it costsThe quota applies to each partner separately. Two partners with 100/d give two hundred messages per receiver — twice as many as calculated.
How to spot itThe daily volume of cold addresses is a multiple of the number of partners.
How to do it rightDivide the intended number by the number of partners — or keep one.

Assigning a live production address as the partner

§ 11.6

What it costsThe mechanism is designed the other way around: the cold address should be a new one building history. By sending traffic to an established one you warm up nothing, you merely shift the load.
How to spot itThe “warming up” address already has normal deliverability, and it does not change.
How to do it rightAssign as the partner the address being put into service.
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
cold-virtual-mta <name>
Values
the name of a declared sending address
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<virtual-mta>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <virtual-mta> and is inherited in the usual order: written in <virtual-mta-pool>, it goes to every member, and a member’s own line overrides the pool one. The manual lists it among the seven directives supported at the pool level. The partner itself, meanwhile, inherits nothing from the one that hands it messages.
How to check on the node
That the partner is assigned and working is visible in accounting — its name should appear on the first messages of the day:
pmtaacctfind --output csv[vmta,rcpt,timeLogged] /var/log/pmta/acct-*.csv
If the partner’s name is not there at all, check the second half: without max-cold-virtual-mta-msg the line does nothing. If it is there but the volume is larger than expected, remember that the quota is counted per receiver and per partner separately.
In the Hub
Cost of a mistake
disruptive: applying it interrupts the node
Scenarios
Sending address rotation · Address warm-up