Knowledge base

The sending address — what it is made of

critical

<virtual-mta>
Everything that is a property of the address lives here

A sending address in PowerMTA is not a line with an IP but a named block of settings. It collects what belongs to the address as such: which IP the message leaves from, what name the node introduces itself with to the receiving server, which key it signs with, which proxy it goes through and how fast it sends overall.

Fifteen directives, and most are familiar. These are the same names as at the node level in part one of the manual, only narrowed down to one address: smtp-source-host, smtp-proxy-source-host, host-name, domain-key, include-headers-from, use-proxy, proxy-protocol, proxy-include-tlv. Written here, they act only on messages that left from this address.

Three directives exist only here. max-smtp-msg-rate and max-smtp-data-volume-rate limit the address as a whole, not each queue separately — there is no other way to set a ceiling per address. cold-virtual-mta names the partner address that early traffic is diverted to.

About the partner the manual states an important negative: the cold address inherits nothing from the one that redirects to it. Either it is configured from scratch in full, or it has no settings at all.

Receiver blocks can sit inside an address. Then the receiver policy and the address settings add up rather than replace each other: the address gets both an overall ceiling and one for each receiver. How exactly nesting is resolved is on the domain-matching page.

The address does nothing by itself. It applies only when a message has been assigned to it — and the choice is made by a separate ladder of six methods (vmta-selection-precedence).

The main trap is a half-configured cold partner. The manual warns about it directly, but that line is rarely reread: cold-virtual-mta inherits nothing. It inherits neither the source address, nor the greeting name, nor the signing key. A partner that someone forgot to give smtp-source-host sends from the default address; forget domain-key, and messages leave unsigned. The early traffic the partner exists for is the most sensitive to both slips.
What the Hub does. It builds one such block for each sending address — this is the backbone of the working configuration. The block gets the source address with the node name, the signing key and the streams, and inside it a receiver block with the pace and backoff mode.

The Hub writes the address blocks to /etc/pmta/virtualhost.txt, and the sending addresses that go through proxies to a separate file, /etc/pmta/proxy.txt; the main file includes both with include lines. The format is shared with Protosender — both read the addresses file.

The Hub does not create cold partners: warm-up is managed by its own scheduler, which can stop on the spam rate and swap in an address from the reserve pool. The engine’s early-traffic mechanism knows nothing about that.

Recommended values

The mechanism has no values of its own — the directives inside the block set them. What goes into the block depends on the address’s role:

What kind of address What the block must have
production mailing address source, node name, signing key, streams, queue pace
address in warm-up the same plus a lowered pace; the scheduler holds the quota
reserve address a full copy of the production one: nothing is inherited from the address it replaces
cold partner everything from scratch — it inherits nothing

The block name is the name all other parts of the configuration will see. The address is selected by it through a header, a pattern rule and a source default; it is also printed in accounting and in node summaries. Changing the name of a working address means changing it in all those places at once.

The roles table is ours, from the Hub’s practice. From the manual here are the block’s composition, its three own directives and the rule that a cold partner inherits nothing.
Example configuration
# sending address: address properties outside, receiver policy inside
<virtual-mta mta-news-1>
    smtp-source-host 1.2.3.4 news1.example.com    domain-key sel1,example.com,/etc/pmta/keys/sel1.pem
    max-smtp-msg-rate 3000/h
    <domain *>
        max-msg-rate 500/h
        backoff-max-msg-rate 1/h
    </domain>
</virtual-mta>
The highlighted line sets both the IP and the greeting name — they always go together. The top three lines describe the address, the lower block describes how this address behaves with each receiving server; the address ceiling and the queue pace act at the same time.
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▶

Creating a cold partner without repeating the settings

§ 3.3.12.4

What it costsThe partner inherits nothing from the address: neither the source, nor the greeting name, nor the signing key. Early traffic — the most vulnerable kind — leaves from the default address and unsigned.
How to spot itMessages from the first days leave from the wrong IP or arrive unsigned, even though everything is configured on the main address.
How to do it rightConfigure the partner in full, as an independent address. Compare both configurations with the command that prints address parameters.

Looking for the address ceiling among receiver settings

§ 3.3.12

What it costsLimits in a receiver block count a single queue: 500/h with ten receiving servers is five thousand messages an hour from the address. A ceiling on the address as such is set only by two directives of this block, and there is no other way.
How to spot itThe actual sending from the address is a multiple of the calculated amount, and the multiple equals the number of receiving servers.
How to do it rightSet max-smtp-msg-rate or max-smtp-data-volume-rate in the address block itself. Check with the address settings command.

Renaming a working address

§ 3.3.12

What it costsThe block name is what the address is selected by: a message header, a pattern rule, a source default. Renaming breaks all these references at once, and messages go to the wrong place or do not go at all.
How to spot itAfter the configuration edit, some messages go from the default address, and an unfamiliar stream name appears in accounting.
How to do it rightChange the name only together with everything that refers to it. It is simpler to create a new address and move sending to it than to rename a working one.
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 block itself has no inheritance: it is either selected for a message or not. The directives inside it inherit. An address that belongs to a pool gets the pool settings as its own, not a share of them — and its own line overrides the pool one. A receiver block inside an address combines with node-level receiver blocks under the usual merge rule. It is picked up by pmta reload.
How to check on the node
What the address actually got — after merging with the pool and the defaults — is printed by a separate command:
pmta show vmta-settings mta-news-1
pmta show vmtas
The first shows the settings of one address: source, name, keys, ceilings. The second gives a summary of all of them: how many recipients, kilobytes and connections each has right now. The queue settings inside an address are printed by a third command, pmta show settings domain/address.
In the Hub
Cost of a mistake
disruptive: applying it interrupts the node
Scenarios
Sending address rotation · Address warm-up · Sending through proxies
Priority
critical