Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.63

smtp-service

<source>criticalset by the Hub

Whether to offer SMTP to connections from this source
in the configuration this is a linesmtp-service trueinside the block <source>
Whether submission is open for this source

Whether SMTP is offered to those connecting from this source’s addresses. Turning it off closes submission pointwise without touching the others: the listener keeps working, but answers a specific network with a refusal.

The refusal is polite and immediate. Instead of the usual 220 greeting, a closed source gets 521 <node-name> does not accept mail from you — and the connection is closed. The client learns the reason immediately, not through a timeout.

The default is “open.” So closed submission is built deliberately: the manual shows exactly one technique — deny in the general <source 0/0> block and allow in the blocks of the submitting platforms. Allowing blocks alone close nothing.

This is the fastest way to cut off a submitter. No restart is needed, messages in the queue are not touched — the only thing that changes is whether the node accepts new ones.

The main trap. The source is chosen by merging all matching blocks, and a narrow entry overrides a wide one. If you close submission in the general block and forget a named source with a more precise address, you close nothing.
What the Hub does. It writes smtp-service yes both in the general <source 0/0> block and in every submission source. That is, the node greets anyone who can reach it: we have no closed-by-default submission — it is held back by other lines, the relaying permission and the login requirement. There is no separate “stop submission” operation in “Control” either: there you stop the service as a whole, and that breaks delivery too.
Recommended values

Close in the general block, open in the specific ones. The reverse order does not work: the default is “open,” and everything not named stays open.

A node that receives bounces and complaints must not be closed. Reports come from the recipients’ mail services, and their addresses cannot be listed in advance. A closed general block will cut off both submission and all receiving from the MX side at once.

Separate nodes, not sources. If report receiving and campaign submission live on the same node, this directive stops being a precise tool — you can close only what neither of them needs.

All from the manual: the default, the refusal text and the “deny in the general block, allow in the specific ones” technique.
Example configuration
# the submitting platform — open and with the right to relay
<source 10.0.0.1>
    smtp-service yes
    always-allow-relaying yes
</source>

# closed to everyone else
<source 0/0>
    smtp-service no</source>
Both blocks are from the manual, together with its own comment about submission sources. The order of lines does not matter — the most precise match wins.
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 ends4 mistakes▶

Adding allowing blocks without closing the general one

§ 3.3.7.63

What it costsThe default is “open,” and listing your own forbids nothing to outsiders. The restriction exists only in the head of whoever configured it.
How to spot itThe node greets anyone who connects with 220, even though “only our own platforms are configured.”
How to do it rightWrite smtp-service no in the <source 0/0> block and open pointwise.

Closing the general block on a node that receives reports

our experience

What it costsReports come from the recipients’ mail services, not from your addresses. A closed general block answers them with 521, and the report is lost forever — nobody is obliged to retry it.
How to spot itComplaints and asynchronous bounces disappear; accounting has no receipt records, even though the MX record is in place and the port is open.
How to do it rightOn a node that combines submission and receiving, do not close this directive; build protection with the login requirement and relaying rights.

Assuming closed submission stops sending

§ 3.3.7.63

What it costsThe directive decides only whether the node accepts new messages. Everything already in the queue keeps being delivered on schedule.
How to spot itSubmission was closed to “stop the campaign,” yet messages keep going out.
How to do it rightStop delivery with queue operations — pause or backoff mode — not by closing submission.

Checking from a workstation instead of the platform's address

§ 3.3.7

What it costsThe source is chosen by the address of the one connecting, and the node’s reply depends on where the connection came from. A check from the wrong address says nothing about the platform.
How to spot itThe check shows 521, even though the platform submits without problems — or the other way around.
How to do it rightCheck from the platform itself or through the listener it connects to.
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-service <boolean>
Values
yes | no | true | false; the default is true, that is, submission is open
Default
true § 3.3.7.63
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
<source> blocks merge from general to exact; the narrow one overrides the wide one. A listener can assign a source bypassing this rule — with the source= parameter on the smtp-listener line: then the named block applies, not the one that matches by address. It is picked up by pmta reload.
⇄

Related directives

2 relations

Works together with

smtp-listenerGlobalThe listener opens the port, and this directive decides whether to accept mail on it from the source. § 3.3.1.27

Applies to

How the node selects a source and combines its settingsSource merging is what makes the “deny in the wide block, allow in the narrow one” technique work. § 3.3.7.63

How to check on the node
Check it with the greeting: connect to the listener from the side you are checking and look at the first line of the reply:
printf 'QUIT\r\n' | nc -w5 node 2525
220 … — submission is open to this address, 521 … does not accept mail from you — closed. Check from the very address in question: the source is chosen by the address of the one connecting.
◇

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
Managed at
Infrastructure → Node parameters
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Node security · Connect a sending platform
Priority
critical
Neighboring settings of the block <source>:retain-x-dkim-keyprocess-x-dkim-keyallowed-sender-listsrequire-authallow-unencrypted-plain-authAll 74 directives of the block →