Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.54.1

always-allow-relaying

Globalcriticalset by the Hub

Allow a source to submit mail for any recipients
in the configuration this is a linealways-allow-relaying falseinside the block Global
Who is allowed to send anywhere through this node

The default is false. The line allows the named source to send mail to any recipient — that is, not only to the domains the node has declared its own.

The manual’s advice is direct: enable it in the source blocks of internal machines that submit mail to the node over SMTP.

This is the very thing a mail node exists for as a sender — and the thing that turns it into an open relay if the source is specified wrongly.

Out of the box, relaying is forbidden. Until sources are explicitly allowed, the node accepts submission only from the 127.0.0.1 address.

The main trap is the subnet mask. A source is given as an address or a network, and 0/0 means “anyone.” One character separates “works” from “disaster” here.

The second half is quieter: a right granted by address does not survive a move. The platform switched hosting providers — submission stopped, and the usual cure is widening the mask. The widened mask stays forever.

The way out of both traps is the same — tie the right not to an address but to an account: grant the permission to the login’s named source, which only logged-in clients get into.

What the Hub does. It writes it — both by address and by login.

The 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 clients logged in with a login 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. For a submitting side that logs in, a move breaks nothing — the login stays the same; an address on the list has to be edited after a move.

Recommended values

What to set. The question is not the value but which block to give it to:

Where What you get
the login’s named source the right follows the account: a move does not break submission, revocation is possible
your platform’s narrow subnet works until the address changes
0/0 an open relay — never the right option

The first is the only layout that does not fall apart on a move and lets you revoke access for a single sender.

The false default, the advice to enable it in internal sources and the ban on external relaying out of the box come from the manual, § 3.3.1.54.1 and § 2.3. The “which block to give it to” breakdown is ours.
Example configuration
# the right follows the login, not the address of the submitting machine
<source {pmta-auth}>
    require-auth true
    always-allow-relaying yes</source>
Only logged-in clients get into this block: it is selected by login, not by address. Moving the submitting platform does not break this arrangement.
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▶

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 — if it recovers at all.
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 grant the permission to the login’s named source.

Putting the permission in the wide block and the ban in the narrow one

§ 3.3.1.54.1

What it costsMerging goes by narrowness, not by the order of lines: the permission from the 0/0 block goes to every subnet that has not said otherwise itself. A restriction meant to be strict does not work.
How to spot itAnyone can submit mail, even though the narrow block looks restrictive.
How to do it rightThe ban goes into the wide block, the permission into the narrow one.

Tying the right to the submitting platform's address

our experience

What it costsA move of the platform to another hosting provider stops submission. The cure is widening the mask, and the widened mask stays forever.
How to spot itThe configuration has masks wider than needed, and nobody remembers where they came from.
How to do it rightGrant the permission to the login’s named source: the right follows the account.
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
always-allow-relaying <boolean>
Values
yes | no | true | false
Default
false § 3.3.1.54.1
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global, <source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source> and obeys source merging: a connection falls under all the address blocks that cover it, and the narrow one overrides the wide one. Hence the rule: the ban goes into the wide block, the permission into the narrow one. The other way around does not work.
⇄

Related directives

4 relations

Conflicts with

smtp-listenerGlobalThe listener decides where the node can be reached from at all; this line decides what those who reach it are allowed to do. § 3.3.1.27

Can be replaced by

relay-domainGlobalThe other half of the question: not who submits to us, but for whose addresses we accept. § 3.3.1.54.2

Applies to

Who is allowed to submit mail and for whom to accept itOne of the two halves of the relay question: this one is about the right to submit mail to us. § 3.3.1.54.1Who can submit mail and on what termsThe permission is granted to a source block and obeys its merging. § 3.3.1.54.1

Referenced from

relay-debugGlobalDebug mode softens the refusal issued by relay control — the very one this line opens. § 3.3.1.54.4source<smtp-listener>Relaying permission for this port is taken from the named block, not from the address block. § 3.3.17.3

How to check on the node
Check the behavior, not the line — and always from someone else’s machine:
grep -n -B3 'always-allow-relaying' /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
A 250 reply on the RCPT line from an outside address means an open relay. The first command shows in which blocks the permission is granted: look at the block specifically, not at the mere presence of the line.
◇

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 → Sending addresses
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 Global:smtp-listenerrelay-debugrelay-addresspickuprelay-domainAll 108 directives of the block →