Demo
Demo

Knowledge base

PMTA knowledge base›Block <smtp-listener>›Directive§ 3.3.17.3

source

<smtp-listener>

Which named source applies to this listener's connections
in the configuration this is a linesourceinside the block <smtp-listener>
The same name 1:<smtp-listener><smtp-user>— some of them are other settings, some are the same one
Rights by listener, not by address

The line names the <source> block whose settings apply to connections accepted at this listener’s address. The manual describes the result in one word: they override what matching by the sender’s address would have given.

There is no default: if it is not written, the usual matching applies.

The same can be written as a parameter right in the node-level listener line (smtp-listener 1.2.3.4:25 source=mta1) — these are two forms of one setting.

What it is for: separating ports. One port accepts submission with broad rights, another accepts inbound mail, where relaying is forbidden and only receiving complaints is allowed.

The main trap is that the override is stronger than the address. A connection arriving at such a listener gets the named block’s settings regardless of where it came from. The rule “narrow the source block down to your own network” stops working on this port: the block is chosen by the listener, not by the address.

So all address-based restrictions for this port have to be set either in the named block itself or as a range in the listener’s address.

What the Hub does. It does not write it: it declares listeners with node-level lines without the parameter, and keeps rights separation on logins — the named source is chosen by source inside <smtp-user>, not by the listener.

The difference is significant: for us rights are tied to the account and apply from any address, whereas this directive would tie them to a port.

Recommended values

What to set. The value is a block name; the question is what to separate rights by:

Value When
do not write it rights are separated by login or by address — the usual case
a block name ports have different roles: submission on one, inbound mail on another

If the line is needed, the named block must contain the full set of rights for this port: we do not advise relying on missing settings coming from address blocks.

The purpose, the word “overrides” and the equivalent form with the source= parameter in the listener line come from the manual, § 3.3.17.3 and § 3.3.1.27. The advice to write out the full set is ours, from experience with named login sources.
Example configuration
# the complaint receiving port has its own rights: relaying is forbidden
<source inbound-only>
    smtp-service yes
    max-message-size 30M
</source>

<smtp-listener 0/0:25>
    source inbound-only</smtp-listener>
A connection on this port will get the named block’s settings from any address. It has no relaying permission — so other people’s mail cannot be handed over through this port.
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▶

Expecting the address-based restriction to remain in effect

§ 3.3.17.3

What it costsThe named block overrides what was matched by address. The “allow only your own network” rule written in the address blocks does not apply on this port, and anyone who reaches it gets the rights.
How to spot itSubmission from addresses forbidden in the address blocks goes through the port with a named source.
How to do it rightSet the restriction in the named block itself or narrow the range in the listener’s address.

Writing only differences in the referenced block

our experience

What it costsSettings left in address blocks may not reach this port’s connections. The same case as with named login sources, where inheritance was not confirmed for us.
How to spot itA setting works on one port and does not work on another with identical submission.
How to do it rightWrite out the full set in the referenced block and verify by behavior.
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
source <name>
Values
a source block name
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<smtp-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <smtp-listener> and applies to one listener. It is not inherited — what is inherited is what it points to: the named block takes effect for connections on this port and overrides what was matched by address. We do not advise relying on anything not mentioned in it coming from address blocks.
⇄

Related directives

3 relations

Conflicts with

always-allow-relayingGlobalRelaying permission for this port is taken from the named block, not from the address block. § 3.3.17.3

Affects

How the node selects a source and combines its settingsCancels the usual address-based block matching for this port. § 3.3.17.3

Applies to

smtp-listenerGlobalThe line applies to connections accepted at this listener’s address; the same is set with the source= parameter in the listener line itself. § 3.3.17.3

How to check on the node
The link between a listener and its block is visible in the configuration; whether it works can only be seen from behavior:
grep -n 'smtp-listener\|^ *source ' /etc/pmta/config
printf 'HELO test\r\nMAIL FROM:<a@example.com>\r\nRCPT TO:<b@example.net>\r\nQUIT\r\n' | nc <node-address> 25
The second command is run from another machine and checks the rights of this particular port. A refusal at RCPT means relaying is closed on it; a 250 response means it is open, whoever the submitter is.
◇

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
Neighboring settings of the block <smtp-listener>:await-slotuse-inbound-proxytls-certificateinbound-proxy-timeoutimmediate-tlsAll 18 directives of the block →