Demo
Demo

Knowledge base

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

pattern-list

<source>set by the Hub

Which rule list applies to messages from this source
in the configuration this is a linepattern-listinside the block <source>
A reference to a selection rule list

One line with a reference. The rule list is declared separately, with a <pattern-list> block, and here it is named — from that moment messages from this source are checked against its rules.

Order in the file. The manual requires declaring the list above the source (§ 3.3.7.42). Engine 6.0 also accepts a forward reference — verified on a node on Sep 15, 2026: the shared login’s source refers to a list declared below in the same file, and messages went through streams by its rules. The manual’s order is worth keeping: on another engine version a forward reference may not resolve. The second restriction is strict: a source has exactly one list — everything this source needs has to be expressed inside it.

What the rules do. They match the return address, the recipient or a header against regular expressions and assign a stream or a recipient priority. The first match wins, so a list is not a set of rules but an ordered queue. The rules see the return address as originally submitted: if the source also rewrites it with rewrite-list, the address before rewriting is matched.

The main trap is “one list per source” combined with inheritance. A narrow <source> block does not add rules to the broad block’s list but replaces the list entirely. A line in a subnet block cancels the general list, and all the rules it had stop working for that subnet at once.
What the Hub does. It writes it itself — a single pmta-pattern list with a rule for each sending domain, assembled from the “domain + address” pairs (they are visible on the node card: “Infrastructure → Nodes”, the “Addresses and domains” block); the rules do not overlap. The list is declared in the node’s address file and attached twice: to the general 0/0 source in the main configuration file and to the general login’s submission source in the address file. The base configuration, which is applied before any pairs exist, has no list.
Recommended values

What to set. The value is the name of a declared list, there is nothing to choose here. The choice comes earlier, when the lists are designed:

Design When Drawback
one list per source the usual case everything in one place, the order has to be maintained by hand
a list calling another (call-to:) the rules naturally fall into groups two levels harder to read

Remember the order in the file: lists above, sources below.

Both restrictions — “one per source” and “declare above” — come from the manual. The remark about the list being replaced through inheritance is ours.
Example configuration
# the list is declared before the source that references it
<pattern-list mta-hub-senders>
    mail-from /@shop\.example\.com$/ virtual-mta=shop-example-com
</pattern-list>

<source {pmta-auth}>
    pattern-list mta-hub-senders    default-virtual-mta mta-hub-pool
</source>
The layout is the same as in the Hub’s working configuration: a list, a reference to it from the submission source, and a default pool. The last line is a safety net: a message that matches no rule goes out through the pool instead of being left without a stream.
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▶

Declaring the list below the source

§ 3.3.7.42

What it costsThe manual calls this a mistake: the list must come before the source. Engine 6.0 resolves a forward reference (verified on a node on Sep 15, 2026), but the behavior is not promised — on another version the configuration may fail to apply as a whole, and the node will stay on the previous one.
How to spot itOn 6.0 — none. If the reload stopped passing after an engine version change, and the error points to the source block, the order is the cause.
How to do it rightKeep the order “lists first, then sources,” as the manual requires.

Adding a reference to a narrow block, expecting the rules to add up

§ 9.4.2

What it costsA source has one list. A narrow block does not add rules to the general list but replaces it — and for that subnet the general rules stop working at once.
How to spot itAfter a “private” list is added, some of the subnet’s senders go out through the default stream instead of the previous one.
How to do it rightGather all the needed rules into one list for this subnet, or use call-to: — calling another list from the first one.
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
pattern-list <name>
Values
the name of a rule list block declared above in the file
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 merges by the source rule: a narrower block overrides a broader one. Lists are not merged in the process — a narrow block replaces the reference entirely, because a source can have only one list.
⇄

Related directives

1 relation

Does not work without

Named selection rulesThe rule list itself: it is declared as a separate block and must appear in the file above the source that references it. § 3.3.7.42

Referenced from

Selecting a sending address by message contentThe line with which the submission block references the list: without it the rules do not apply. § 3.3.7.42header<pattern-list>The rule works only if the list is plugged into a source, and the list is declared in the file above it. § 3.3.7.42mail-from<pattern-list>The rule works only if the list is plugged into a source. § 3.3.7.42rcpt-to<pattern-list>The rule works only if the list is plugged into a source, and the list is declared in the file above it. § 3.3.7.42

How to check on the node
Check the reference — that a list with this name is declared — and the result in accounting:
grep -n "pattern-list" /etc/pmta/config /etc/pmta/virtualhost.txt
pmtaacctfind --output csv[orig,vmta] /var/log/pmta/acct-*.csv | head -20
Every pattern-list name reference must find a <pattern-list name> block — in this file or in an included one; a list above the source is the manual’s order. In accounting, the stream in the vmta field must match the domain of the return address; with rewrite-list the orig field holds the already rewritten address, while the rules matched the original one.
◇

What else to read

3 articles

◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇A return address with the recipient written into itThe bounce arrives at a unique address, and there is no need to parse its content.◇What to return in a bounce reportWhat to enclose in a bounce report: the whole message or only its headers.

In the Hub
Managed at
Infrastructure → Sending addresses
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Bounce classification
Neighboring settings of the block <source>:process-x-jobjobid-prefixallow-mailmergeadd-message-id-headeradd-received-headerAll 74 directives of the block →