Demo
Demo

Knowledge base

PMTA knowledge base›Procedure§ 1.6.1

Restrict who can reach the node at all

Access policies
Five steps of least privilege

The manual groups these measures under one principle — least privilege: give each party exactly the minimum it needs for the job. There is nothing unusual in the list, and that is its strength: this is a baseline setup, not fine-grained protection.

A node has three surfaces, and the steps close them in turn: the right to hand over mail (who is allowed at all), where we accept from (the address range), who can reach the monitor — and, separately, which user the engine itself runs as.

What matters is that all five are expressed in configuration. This means they can be done by construction rather than recommended — which for a fleet is the only way that works: recommendations are followed on the first node and forgotten by the twentieth.

The main trap is that the third step is usually skipped. Narrowing the submission range is harder than the other four: the submitting side’s address changes, nodes sit at different hosting providers, and every narrowing risks breaking submission. So the range stays wide, and protection moves to the password.

This is a legitimate trade-off, but it has a price: all submission protection starts resting on a single secret. So it has to meet everything the range would have had to — a different password per login, a limit on failed attempts, and awareness that everyone can see the open port.

What the Hub does. Three steps out of five — by construction, in every generated configuration. The first: a user block for each “domain plus address” pair plus the pool’s common login. The second: one login method is used — a password; certificates, LDAP and system logins are not used. The fourth: http-access only for local addresses and the Hub’s addresses; the engine responds 403 to everyone else.

The third step — halfway: the submission listener listens on 0/0, and so does the common source block, but 0/0 has no relaying permission. Without a login, mail can be submitted only from the machine itself and from the addresses in “Who may submit mail”; for everyone else the right comes from a login. The reason lies in how the fleet is built — nodes sit at different hosting providers, the submitting side’s address changes, and a strict range would break submission at every move.

The fifth step is not done: the run-as-root no line was removed from the templates on Aug 29, 2026 — one line did not move the node to the pmta user, and the nodes did not meet the other conditions of § 2.2.1. The engine runs as root.

Example configuration
# four steps visible in the node's configuration
run-as-root no
http-access 127.0.0.1 admin
http-access 10.0.0.7 monitor
<smtp-user pmtauser>
    password s3cret
    source {pmta-auth}
</smtp-user>
The fifth step is the first line, the fourth is the next two, the first and second are the user block. The third step is not here: the submission range stayed wide, and protection rests on the login.
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▶

Doing four steps out of five and considering the job done

§ 1.6.1

What it costsThe one skipped is usually the third — narrowing the submission range, the most laborious. The port stays open to the whole internet, and protection moves entirely to the password, which is not held to any special requirements.
How to spot itThe listener listens on 0/0, there is no limit on failed login attempts, and one password serves all logins.
How to do it rightEither narrow the range, or accept the trade-off and back it with a second measure: different passwords and a limit on login attempts.

Restricting the monitor while forgetting the submission port

§ 1.6.1

What it costsThe monitor and submission are different surfaces with different settings. A closed monitor does not stop anyone from connecting to the listener and trying to log in.
How to spot ithttp-access is strictly configured, while smtp-listener listens on the whole network with no restrictions in the sources.
How to do it rightTreat the surfaces separately and check each from outside.

Checking the measures on the node itself

§ 1.6.1

What it costsDifferent rules apply to a local address: the monitor lets you in, and a source of its own is matched. A check from inside does not show what an outsider sees.
How to spot itThe check was done over SSH on the server itself.
How to do it rightCheck from another machine, and separately — which user the process runs as.
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.
⇄

Related entries

4 relations

Does not work without

http-accessGlobalThe directive that restricts access to the monitor; described in chapter 3. § 1.6.1Who can submit mail and on what termsRestricting receiving is expressed with source blocks and address ranges. § 1.6.1An account for submitting mailThe right to relay is granted to an account, not an address. § 1.6.1

Works together with

Lock down permissions on configuration filesHere it is network access, there file permissions. You need both or neither. § 1.6.3

Referenced from

Who is allowed to submit mail and for whom to accept itThe first and third steps of the recipe are exactly the two ways of deciding who is allowed to relay. § 1.6.1Running without root privilegesA related procedure: they share some of the steps. § 1.6.1What protects the web monitor and what that protection is notNarrowing access to the monitor is one of the recipe’s five steps; the rest are about mail submission. inference

How to check on the node
Check from outside — from inside the node all four measures look implemented:
grep -n 'run-as-root\|http-access\|smtp-listener' /etc/pmta/config
ps -o user= -p "$(pgrep -n pmtad)"
curl -sS -o /dev/null -w '%{http_code}\n' http://<node-address>:1000/
The third line is run from another machine and must return 403: the monitor responds but does not let you in. The first shows what is written; the second shows which user the engine actually runs as, rather than which was intended.
◇

What else to read

3 articles

◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.◇Submission logins, plain-text passwords and per-user settingsA sender logs in with one of three methods; each login is a configuration block with a plain-text password, and that login’s named source overrides what its address would have given.◇A license for a fleet, not for a serverThe license is not bound to a server: it is installed on as many machines as the instance limit allows, and the nodes send volume statistics to the vendor every hour.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Sender isolation