Knowledge base

A name, an address and a greeting name — what a sending address consists of

critical

VirtualMTA definition
What must be in a sending address definition

The construct is simple: a block with a name, and inside it an address and a greeting name. Two things about it usually go unknown, and both are costly.

First: omitting inherits. A sending address without an smtp-source-host line (or its proxy form) takes the node’s general address set. It is neither an error nor a warning — messages leave successfully, but from the wrong address. The vendor notes this twice and advises setting at least one line in every definition. It also gives an instructive example: a block name that looks like a domain does not serve as the greeting name — the name needs a separate entry.

Second: several addresses in one definition are used round-robin. That is, a sending address is a group of addresses, not necessarily one. Before treating “identity” and “address” as synonyms, it is worth checking this: any per-address reputation model will be wrong if an identity turns out to be a set.

Definitions reload without stopping the node. And the directives inside apply only when this sending address is chosen for a message; the rest of the time they are simply not read — not an error, just silence.

The main trap. An incomplete definition is a working configuration. No error on apply, no warning: a sending address without its own address line sends from the node’s general set, and this is discovered through discrepancies in accounting volumes, not through diagnostics.
What the Hub does. It assembles definitions itself, from the “sending domain + bound address” pair on the node card (“Infrastructure → Nodes”, the “Addresses and domains” block): the block name, the address line with the domain as the second word, the signing key, limits and receiver rules. The address line is always written — there are no omissions. What the Hub does not do yet is check other people’s definitions: on a node someone had worked on before the Hub, an incomplete sending address will go unnoticed.
Recommended values

The mechanism has no values of its own — the directives inside the block set them. What is required in a definition and what depends on circumstances:

Line Required Why
smtp-source-host or the proxy form yes otherwise the node’s set is inherited — silently
the name as the second word of that line yes the block name does not serve as the greeting name
domain-key practically large receivers treat unsigned messages with distrust
max-smtp-out and receiver rules depending on circumstances they can be kept on the pool, shared by the group

A one-line check for the configuration generator: every sending address has an address line with a name in it. The engine accepts a definition without one, and that is a hidden configuration error.

Both properties — inheritance on omission and round-robin rotation — come from the manual (§ 9.2), with the vendor’s direct advice. The list of what is required is ours.
Example configuration
# a full definition: address, name, signing key, limits
<virtual-mta shop-example-com>
    smtp-source-host 203.0.113.10 shop.example.com    domain-key sel1,shop.example.com,/etc/pmta/keys/private_key_shop.txt
    <domain *>
        max-smtp-out 20
    </domain>
</virtual-mta>

# incomplete: the engine accepts it, messages leave from the node's general set
<virtual-mta broken>
    <domain *>
        max-msg-rate 100/h
    </domain>
</virtual-mta>
The second block is not a made-up case but what you get when a sending address is created “for limits” and adding the address line is forgotten. There will be no error on apply, the limits will work, and messages will leave from the wrong address.
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 sending address without an address line

§ 9.2

What it costsThe definition is accepted and messages go out — from the node’s general set. The identity exists in name, but by address it coincides with all the others.
How to spot itSeveral sending addresses have the same delivery address in accounting; warm-up follows the plan, but the reputation built is that of the “wrong” address.
How to do it rightSet the line in every definition. The vendor advises this directly, and the check in the generator costs one line.

Taking the block name for the greeting name

§ 9.2

What it costsThe sending address name is an identifier, and it does not get into the greeting, even if it looks like a domain. The node will introduce itself with whatever resolution finds — most likely the node’s general name.
How to spot itEHLO has a name that is not in any sending address block.
How to do it rightSet the name as the second word of the address line. The manual gives this case as a separate example precisely because people trip over it.

Treating a sending address as a single address

§ 9.2

What it costsSeveral address lines in one block give round-robin rotation. A “one identity — one address” reputation model on such a node attributes someone else’s history to the addresses.
How to spot itIn accounting, the delivery address field of one sending address takes several values.
How to do it rightEither one line per definition, or count reputation by the delivery address field from accounting rather than by the sending address name.
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 definition itself has no inheritance: the directives inside it are inherited. There are three levels — the node, <virtual-mta-pool> and the sending address itself — and the closer to the message, the stronger. Omission deserves a separate note: an address line not set in the block does not “stay empty” but is taken from the node level.
How to check on the node
Whether a definition is complete shows in the settings summary of each sending address:
pmta show vmta-settings vmta1
A sending address must have the Source Host IP and Source Host columns filled in, and different sending addresses must have different addresses — compare the output for each one. The same address on several of them is a sure sign that the line is missing from the blocks and they all inherit the node’s set.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation · Prepare a node for sending
Priority
critical