PowerMTA: A node that answers only its own fleet

Submission is closed to everyone except those we know

The task. Any fleet node: the submission port must serve the platforms the Hub knows and no one else, and the MX port must accept reports without becoming a loophole inside.

What it is made of:

smtp-service — off in the common 0/0 source, on for submission addresses;
always-allow-relaying — only for submission sources and never for a source tied to an open listener;
reserved-smtp-in — a reserve of inbound connections for the submission group;
allowed-sender-lists — on whose behalf the source may send.

The parts have different scopes. All four are set on a source or a source group and depend on source merging: a lenient 0/0 provides defaults that narrow entries do not override.

How they interact. The manual gives the smtp-service scheme directly, and warns separately about always-allow-relaying in an open listener’s source. The reserve and the sender lists are ours: the first because submission and reports on MX share one inbound node limit, the second because otherwise nothing stops a source from sending on behalf of someone else’s domain.

The main trap is closing 0/0 and forgetting the MX port. Bounce reports and complaints come from any addresses and fall into 0/0: smtp-service turned off there closes them too — the MX listener needs its own source via source=, without relaying permission.

What the Hub does. It applies it partially. Relaying permission is granted only to the 127.0.0.1 source, to the addresses in “Who may submit mail” and to named login sources; the general 0/0 does not have it, and the Hub writes no sources attached to a listener. The rest is missing: smtp-service yes is set in 0/0 too — reports to the MX port are received through it — incoming slots are not reserved for submission, and whom a source may pose as is not limited.

Recommended values

Four lines:

Line	Where	Value
smtp-service	0/0	no; for submission addresses and the MX listener’s source — yes
always-allow-relaying	submission sources	yes; nowhere else
reserved-smtp-in	the submission source group	how many connections the platforms hold
allowed-sender-lists	submission sources	lists of senders the source may send on behalf of

The closed 0/0, the warning about the listener’s source, the reserve and the sender lists come from the manual (§ 3.3.7.63, § 9.4.3, § 3.3.9.2, § 3.3.7.43). The reserve and lists in this scheme are our hypothesis.

Example configuration

smtp-listener 0/0:2525
smtp-listener 0/0:25 source=mx-reports
<source 0/0>
    smtp-service no</source>
<source 203.0.113.20>
    smtp-service yes
    always-allow-relaying yes
</source>
<source mx-reports>
    smtp-service yes
</source>

Submission goes to 2525 and is decided by the source address, reports go to 25 through their own source without relaying; the 0/0 and 203.0.113.20 blocks are the manual’s example, and a refusal in them shows as a 521 greeting.

yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.

Knowledge base

A node that answers only its own fleet

Sending scripts

MTA & delivery

Ecosystem

Information