Demo
Demo

Knowledge base

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

allowed-sender-lists

<source>

Which lists the sender address is checked against at submission
in the configuration this is a lineallowed-sender-listsinside the block <source>
Who may sign with whose name

The directive names one or more address lists, comma-separated. Two addresses are checked: MAIL FROM from the protocol and the sender address from the message itself — from the Sender header, or from From if there is none.

A message that fails the check is rejected with the reply 550 5.7.1 Forbidden Sender Address. The refusal is synchronous: the sender learns about it immediately, and the message does not get into the queue.

Without the directive, all senders are allowed — that is its default.

The lists are declared with <address-list> blocks and filled with addresses, local parts, domains and patterns.

The main trap is that two addresses are checked while people think of one. It is usually set up for MAIL FROM, forgetting that the message header is checked too. A platform whose envelope and visible sender differ — and they almost always differ when a return address for bounces is configured — hits the second address.

The other edge: without the directive everything is allowed. That is, a logged-in sender can by default sign with any address — including another domain on the same node.

What the Hub does. It does not write it: there are no allowed sender lists in the configuration, which means a logged-in login can submit a message with any sender address.

Domain separation in the Hub rests not on this but on the choice of sending address: each login has its own named source with its own stream, and mail leaves from the assigned address regardless of what the message says. But the name in the message is not checked by anything.

Recommended values

What to set. The value is list names; what you choose is the degree of strictness:

Value When
do not write it (default) the senders are trusted, and the submitting platform controls the name in the message
a list of domains several senders use the node, and each must sign only with its own
a list of addresses submission comes from fixed addresses and changes rarely

A list of domains is more convenient: addresses within a domain change, domains do not.

The check of two addresses, the Sender→From order, the refusal code and the “all are allowed” default come from the manual, § 3.3.7.43. The breakdown by strictness is ours.
Example configuration
# the list is declared separately, the source refers to it
<address-list sender1>
    domain shop.example.com
</address-list>

<source {shop-example-com-auth}>
    allowed-sender-lists sender1</source>
This login will be able to submit a message only in the name of its own domain. An attempt to sign with someone else’s will get a 550 5.7.1 Forbidden Sender Address refusal right at submission.
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▶

Setting it up for the envelope and forgetting the message header

§ 3.3.7.43

What it costsBoth addresses are checked. A platform whose return address for bounces differs from the visible sender will pass the first check and hit the second.
How to spot itMessages are rejected with 550 5.7.1 Forbidden Sender Address, even though MAIL FROM is in the list.
How to do it rightAdd both domains to the list — the envelope’s and the message’s — or list domains rather than addresses.

Relying on stream selection instead of checking the name

§ 3.3.7.43

What it costsThe stream decides which address a message leaves from, not whose name it is signed with. A logged-in sender can sign with someone else’s domain, and the message will leave from your address in their name.
How to spot itDelivered messages contain sender domains that were never given to this login.
How to do it rightAdd an allowed sender list to each login’s named source.

Putting the list in a wide block

our experience

What it costsBy the merge rule the list goes to all subnets, and different senders get the same set of allowed names. The separation all this was for disappears.
How to spot itOne list is named in the 0/0 block and nowhere else.
How to do it rightPut a separate list in each login’s named source.
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
allowed-sender-lists <list>
Values
list names, comma-separated
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
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. A list named in a wide block will also go to the narrow ones — and since each login has its own set of allowed names, it makes sense to put it precisely in named sources.
⇄

Related directives

2 relations

Does not work without

Address lists — named and unnamedLists are declared with an address list block and filled with addresses, domains and patterns. § 3.3.7.43

Works together with

suppression-lists<source>A neighboring check of the same kind, only by recipient rather than by sender. § 3.3.7.41

How to check on the node
The reference and the list itself are visible in the configuration; whether it works is checked by trying to submit under someone else’s name:
grep -n 'allowed-sender-lists' -A3 /etc/pmta/config /etc/pmta/virtualhost.txt
grep -n 'Forbidden Sender' /var/log/pmta/pmta.log | tail -5
A missing line means all senders are allowed. It is worth checking with both addresses: first with someone else’s MAIL FROM, then with someone else’s From and your own envelope — the second case is caught less often.
◇

What else to read

3 articles

◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.◇Submission logins, plain-text passwords and per-user settingsA sender logs in with one of three methods; each login is a configuration block with a plain-text password, and that login’s named source overrides what its address would have given.◇A license for a fleet, not for a serverThe license is not bound to a server: it is installed on as many machines as the instance limit allows, and the nodes send volume statistics to the vendor every hour.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Sender isolation
Neighboring settings of the block <source>:smtp-serviceretain-x-dkim-keyprocess-x-dkim-keyrequire-authallow-unencrypted-plain-authAll 74 directives of the block →