Knowledge base

The stream follows the address you connected to

selection by listener
Its own submission address — its own stream

The mechanism rests on named source blocks. An ordinary <source> block is selected by the submitter’s address; a named one is not selected by itself, but is attached to a listener with the smtp-listener directive, and from then on applies to everyone who connected to the given address and port. default-virtual-mta sits inside such a block.

There can be any number of listeners — on different addresses and ports, each with its own named source and, hence, its own default stream. The sender only has to choose where to connect.

The vendor accompanies this with a warning, and it is important. A named source applies to everyone who can reach the address and port — so permissions must not be granted there: neither relaying nor merge access. Permissions are granted by authentication or by sender address. On a listener only one thing is appropriate — stream selection.

The main trap is confusing “selection” with “permission”. An always-allow-relaying yes line in a named source turns the listener into an open relay for everyone who reaches it: there is no sender address check here any more, the block is selected by the mere fact of connecting. The manual writes about this explicitly.
What the Hub does. It does not use it: the Hub declares two listeners — the submission port and the port for receiving complaints and bounces, both on all addresses (0/0) and without a source= reference. The stream is selected by the submission login, by the X-Virtual-MTA header, by a rule on the return address domain, or by the address the connection arrived at (by-smtp-source-ip) — the last solves the same task without a listener per address.

The method stays in reserve for the case “a platform needs its own entry point”: give it a separate address and port, and it gets its own stream without changing anything on its side.

Recommended values

The mechanism has no values of its own: it is assembled from two directives — smtp-listener with a source= reference and default-virtual-mta inside the named block. What may and may not be written in such a block:

Line Allowed Why
default-virtual-mta yes, this is the whole point stream selection, not a permission
always-allow-relaying no applies to everyone who reached the address
allow-mailmerge no the same, plus the top step of selection
limits and timeouts yes these are receiving properties, not permissions
The ban on permissions in a named source comes from the manual, as a direct warning. The breakdown into table rows is ours.
Example configuration
# each address has its own entry point and its own default stream
<virtual-mta vmta1>
    smtp-source-host 203.0.113.10 vmta1.example.com
</virtual-mta>

<source vmta1>
    default-virtual-mta vmta1</source>

smtp-listener 203.0.113.10:25 source=vmta1
smtp-listener 0.0.0.0:25
Whoever connects to 203.0.113.10 sends via the vmta1 stream. The second listener is kept on purpose: without it the node would stop accepting mail on all other addresses. The <source vmta1> block has no permissions at all — they are granted in other sources, by sender 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 ends2 mistakes▶

Granting permissions in a source attached to a listener

§ 9.4.3

What it costsA named source is selected by the mere fact of connecting to the address and port, without any check of who connected. An always-allow-relaying yes line in it turns the node into an open relay for everyone who reaches that address.
How to spot itMail from unknown senders passes through the node; accounting shows return addresses from domains you do not own.
How to do it rightKeep only stream selection in a named source. Grant permissions by authentication or by sender address — in separate <source> blocks.

Removing the general listener after declaring a named one

§ 9.4.3

What it costsA listener is not an addition to the default but the full list of what the node listens on. By declaring only 1.2.3.4:25, you stopped accepting mail on all other addresses, including receiving bounces and complaints.
How to spot itSubmission from some addresses works, from others the connection is not established at all.
How to do it rightKeep the general 0.0.0.0:25 listener next to the named ones — as done in the manual’s example.
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
A named source does not take part in the general merge of sources: it is not selected by the submitter’s address and applies only where a listener refers to it. That is what makes it a separate mechanism rather than a special case of an ordinary <source> block.
How to check on the node
What the node listens on and with which sources is visible in the configuration:
grep -rn '^ *smtp-listener' /etc/pmta/
The listener line must carry a source= reference with the block name. Without it the connection falls into an ordinary source by sender address, and the stream is taken from there — the mechanism does not work at all.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Connect a sending platform