Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.26

smtp-port

Globaldeprecated

Mail receiving port — the deprecated half of a pair
in the configuration this is a linesmtp-portinside the block Global
The other half of the same pair

The line set the port on which the node accepts mail connections. The address was set by the neighboring line — smtp-ip — and the setting was split in two. The manual section consists of one sentence: “deprecated, use smtp-listener”.

The mechanism itself is analyzed on the smtp-ip page — both lines were deprecated by a pair of sections and are migrated only together. Here is what concerns the port specifically.

There was one port for the whole node. That is the main limitation of the old form: one pair of lines described one receiving point, while campaign submission and complaint receiving usually live on different ports. The replacement removes the limitation — the file can have any number of smtp-listener lines, and 0.0.0.0 may be repeated.

The implicit default belongs to the replacement, not to this line. If the file has no smtp-listener line, the engine starts a listener on 0.0.0.0:25 by itself — port twenty-five opens without any line in the configuration.

The main trap is believing the port is set because the line is there. One smtp-listener line anywhere in the file — and the engine stops reading both lines of the old pair. The port that opens is the one written in the replacement; the port line stays in the file and misleads everyone who reads it.
What the Hub does. It does not write the deprecated pair. It has two ports, and both are set by the replacement: 2525 for campaign submission and 25 for receiving complaints and bounces. The old form cannot express this at all — it can describe only one port.

That is exactly why migrating the pair is not cosmetic: two ports are the very reason the pair was replaced with one repeatable line.

Recommended values

What to set. Nothing: the pair should be replaced.

Value When
do not write always: the port is set by the replacement
port number only in an old configuration that has not been migrated yet

Migration. The port from this line and the address from the neighboring one are joined with a colon. If several ports are needed — and they almost always are — write as many replacement lines: the old form could not describe a second port.

The deprecation mark and the replacement’s name are from the manual, § 3.3.1.26. The repeatability of the replacement line, the implicit listener 0.0.0.0:25 and the rule “smtp-listener present — the pair is ignored” are from § 3.3.1.27. The migration order is ours.
Example configuration
# this is how it was written before — one port for the whole node
smtp-ip 0.0.0.0
smtp-port 25
# this is how it is written now — one line per receiving point
smtp-listener 0/0:2525
smtp-listener 0/0:25
Two ports cannot be described with the old pair: there was one line per node. The two lower lines are what the Hub writes on every node: campaign submission and complaint receiving are split across ports.
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▶

Trying to describe a second port with a second line

§ 3.3.1.27

What it costsThe directive is single-valued: a second line does not add a port but overrides the first. A second receiving point cannot be obtained with the old form — that is why it was replaced.
How to spot itTwo ports are written, one listens — the last one in the file.
How to do it rightMove to the replacement: one smtp-listener line per receiving point, the address may be repeated.

Reading the port from the file without checking whether it listens

§ 3.3.1.27

What it costsThe line stays in the file even after the replacement has devalued it. While investigating a receiving problem, it leads to a wrong conclusion about where the node expects connections.
How to spot itThe submitting system knocks on the port from the configuration and gets no answer.
How to do it rightStart the investigation from the list of open ports, not from the file. Remove deprecated lines as soon as the replacement appears.

Migrating the port while keeping the address

§ 3.3.1.26

What it costsThe pair’s lines were deprecated together and are devalued by the replacement together. The remaining smtp-ip sets nothing, but looks like a receiving address setting — and contradicts the address written in the replacement line.
How to spot itThe file has two different receiving addresses, and no reader can tell which one is in effect.
How to do it rightRemove the pair as a whole. Search for both names with one search — they do not occur separately.
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.
Reference data
Syntax
smtp-port <port>
Values
port number; the manual gives no full grammar for this name
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
Written at the root of the file and applies to the whole instance; no blocks, no inheritance. The replacement has the same scope, but there can be several lines — and that is the only difference that matters in migration.
How to check on the node
Check not the file but what the node actually listens on:
grep -rn 'smtp-port\|smtp-ip\|smtp-listener' /etc/pmta/
ss -lntp | grep pmta
If the list of open ports has a port that is not in any replacement line, the file has no replacement lines at all and the engine opened port twenty-five by itself. If the opposite, the port from the old pair is not listening — the pair has already been devalued by the replacement.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Configuration lifecycle