Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 7.5.4

Submission is a network service, and you can log into it

remote submission with credentials
The submission boundary is the network, not the machine

The submission library offers two connection functions: one connects to the named server and port without any login, the other passes a name and password. The port is the ordinary mail one — the manual directly recommends 25 as the default.

Hence the practical picture. A node’s submission surface is reachable from everywhere its listener is reachable, and the only thing that distinguishes a logged-in sender from one that has not logged in is how the source is configured. A client can always try without a password: whether login is required is decided by the node’s configuration, not by the client.

For a fleet this means that submission rights are a network boundary, not a local one. A source that allows submission allows it from everywhere its address range reaches.

The main trap is that “local” means nothing here. Submission looks like the node’s internal affair as long as the listener listens on 0/0: then the “internal affair” is reachable from the internet, and what protects it is exactly what is written in the source blocks — not the fact that the submitting application sits next to it.

This has to be checked from outside, not from inside the node: from inside everything always looks right.

What the Hub does. It submits remotely and with a password: the warm-up scheduler connects to the node at its address and submission port and logs in with the pool’s common login. The configuration matches: the submission listener listens on 0/0, and the right to hand over mail is granted to named sources, which go to those who log in, and — without a login — to the machine itself and to the addresses in “Who may submit mail”.

A connection from another address that has not logged in gets no relaying permission: the general 0/0 block does not have it. Only the addresses listed by the report-receiving rules will be accepted from it — complaints, bounces and role addresses.

Example configuration
# the submission listener listens on the whole network, the login grants the right to hand over mail
smtp-listener 0/0:2525

<smtp-user pmtauser>
    password s3cret
    source {pmta-auth}</smtp-user>
The port is open to everyone, but mail cannot be handed over through it without login: relaying permission lives in the named source, which goes only to logged-in users.
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▶

Treating submission as the node's internal affair

§ 7.5.4

What it costsA listener listening on the whole network makes submission reachable from the internet. If relaying permission is granted to an address block without a login requirement, the node becomes an open relay — and such nodes are found quickly.
How to spot itThe listener listens on 0/0, and the source block has relaying permission without a login requirement.
How to do it rightEither narrow the listener’s range or grant permission only to named sources, which go to logged-in users.

Checking reachability from inside the node

§ 7.5.4

What it costsFrom inside, the connection comes from a local address and falls into the block written for it. The real surface — the one visible from outside — remains unchecked.
How to spot itThe “everything is closed” check was run on the node itself.
How to do it rightCheck from another machine: first port reachability, then an attempt to submit without a password.
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

3 relations

Depends on

What the submission bindings needA connection with a password is one of the functions of the same submission library. § 7.1How the node selects a source and combines its settingsWhat a remote sender is allowed to do is decided by the source block it falls under. inference

Affects

Who is allowed to submit mail and for whom to accept itThe right to hand over mail through the node — the very thing login is needed for. § 7.1

Referenced from

C submission APIA related mechanism: they work together. § 7.5.4

How to check on the node
Check from outside the node — from inside, the submission surface always looks right:
nc -vz <node-address> 2525
grep -n 'smtp-listener\|always-allow-relaying\|require-auth' /etc/pmta/config /etc/pmta/virtualhost.txt
An open port is not yet open submission: look at who has been granted relaying permission. The dangerous combination is “the listener listens to everyone” plus “permission in an address block without a login requirement.”
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.◇The load balancer header at the entranceThe node reads the PROXY header at the start of an incoming connection and treats the address from it as the source; this works for both kinds of entry point.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Connect a sending platform