Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 2.3

Who is allowed to submit mail and for whom to accept it

critical

relaying control
One word, “relay,” two different questions

Out of the box, external relaying is forbidden. The manual says it directly: until sources are explicitly allowed, the node accepts submission only from the 127.0.0.1 address. Together with the address of the person responsible for the node, this is one of the two settings the engine does not work without.

Next comes the place people trip over most often. The manual uses the word “relay” for two different questions, and they are answered by different directives:

Question Answered by When needed
Who can submit mail to us for anyone always-allow-relaying in the source block sending: the node accepts mail from its submitting machines
For whose addresses we accept mail from anyone relay-domain and relay-address receiving: the node handles inbound mail

The manual stresses: the second pair is useful only where the node handles inbound mail. For pure sending there is no need to configure it at all — the first line does the work there.

Hence the most common confusion: a sender who needs to “allow relaying” reaches for relay-domain because the name fits — and gets nothing.

The main trap is the 0/0 mask in a block with the permission. One subnet mask is all that separates “it finally works” from “an open relay” here. An open relay is found by scanning within hours, and after that someone else’s spam flows through the node, the addresses land on blocklists, and the domain’s reputation takes weeks to recover — if it recovers.

The other edge is quieter and worse for it: a permission by address does not survive a move. The platform changed its address — submission stopped; a wide mask was brought back “temporarily” — and it stayed forever.

What the Hub does. It separates the two questions and answers them differently.

Sending — by an address on the list or by login. The always-allow-relaying yes permission is set in three places: in the 127.0.0.1 source (submission from the machine itself), in a block for each address in “Who may submit mail”, and in every named submission source, which only logged-in clients get into. The general 0/0 block does not have it — so a connection from an address not on the list cannot submit mail without logging in.

The address list suits machines with a fixed address. For a platform that may move to another hosting provider, a login is more reliable: a permission by address would have to be edited on every move.

Receiving — with three pattern rules. The Hub opens receiving for complaints (fbl@fbl.<domain>), for asynchronous bounces (bounce@bounce.<domain>) and for role addresses — dmarc@, postmaster@, abuse@. The last rule did not appear right away: without it, anti-relay bounced DMARC aggregate reports with a 550 relaying denied reply.

Example configuration
# two different questions — two different lines
<source 127.0.0.1>
    always-allow-relaying yes     # who can send through us</source>

relay-address /^bounce@bounce\./    # for whose addresses we accept mail
relay-address /^(dmarc|postmaster|abuse)@/
The first line is about sending, the other two about receiving. If you configure only the latter, you will not be able to send through the node; if you configure only the first, you will get neither bounces nor reports.
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▶

Reaching for receiving when sending is needed

§ 2.3

What it costsThe name relay-domain sounds right, but this pair solves the opposite problem — receiving mail for your domains. It does not grant the right to send through the node, and submission keeps getting refused.
How to spot itThe recipient domains are listed in the configuration, yet submission is still bounced with relaying denied.
How to do it rightAllow submission with a line in the source block, and leave the domain listing for inbound mail.

Opening the relay with a wide mask to make things work

our experience

What it costsThe node becomes an open relay. Within a few hours someone else’s spam flows through it, the addresses land on blocklists, and the domain’s reputation takes weeks to recover.
How to spot itA sharp rise in outgoing volume with no campaign launched; the queues contain domains you do not have.
How to do it rightRemove the wide mask immediately and allow submission by login — then a platform move breaks nothing.

Allowing relaying by address and forgetting about moves

§ 2.3

What it costsThe platform changed its address, and submission stopped. The quick cure is to widen the mask, and the widened mask stays forever, because “it works, doesn’t it.”
How to spot itThe configuration has masks wider than needed, and nobody remembers where they came from.
How to do it rightMove submission to logins: the right follows the account, not the address.
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

always-allow-relayingGlobalThe directive that opens submission for a source; described in chapter 3. § 2.3

Works together with

Restrict who can reach the node at allThe first and third steps of the recipe are exactly the two ways of deciding who is allowed to relay. § 1.6.1

Can be replaced by

relay-domainGlobalThe second question: not who submits to us, but for whose addresses we accept mail. § 2.3

Applies to

Who can submit mail and on what termsThe permission is granted to a source block and obeys its merging. § 2.3

Referenced from

Initial configurationThe mechanism this step relies on. § 2.3total-max-smtp-inGlobalBoth are about acceptance: this ceiling decides how many connections the node can handle, relay control what they are allowed to do. inferencealiasGlobalFor a message to reach expansion, the node first has to agree to accept it — that is decided by the acceptance rules. inferenceHow the node selects a source and combines its settingsThe relaying permission is one of the settings this merging decides. § 3.3.7Two inbound report processors and what to do with themReceiving these messages is allowed not by the processor but by the relaying rules. inferencerequire-auth<source>The second way to solve the same question: a right by login instead of a right by address. § 3.3.7.10

How to check on the node
There is only one real check — try to submit mail from someone else’s machine:
grep -n 'always-allow-relaying\|relay-address\|relay-domain' /etc/pmta/config /etc/pmta/virtualhost.txt
printf 'HELO test\r\nMAIL FROM:<a@example.com>\r\nRCPT TO:<b@gmail.com>\r\nQUIT\r\n' | nc <node-address> 25
The second command is run from an outside address and must get a refusal on the RCPT line. A 250 reply means an open relay — it has to be fixed immediately, not postponed.
◇

What else to read

3 articles

◇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.◇What the submission bindings needWhat must be in place on the submitting side for the bindings to work: a library, permissions and group membership.

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