Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.101

smtp-pattern-list

<domain>set by the Hub

Which pattern list is applied to this recipient domain's responses
in the configuration this is a linesmtp-pattern-listinside the block <domain>
Rules for reading other servers’ responses

The value is the name of a list declared by a <smtp-pattern-list> block. The list is attached to connections with this recipient domain, and its SMTP responses are parsed with it.

Why: receiver responses are not standardized. The same meaning — “you are sending too fast,” “the address does not exist,” “your address is on a blocklist” — is written by each in its own way. The pattern list translates these texts into engine actions, including putting the queue into backoff mode.

Hence the direct connection with backoff-mode: without patterns the engine learns about a problem only from response codes, and the codes are the same for most receivers.

The main trap is that patterns go stale. Receivers change their response texts, and a rule written for the previous text stops matching silently. Backoff mode does not kick in, messages go at the previous rate, and this is discovered through growing bounces, not through a broken rule.

What needs checking is not the attachment line but the response texts themselves in the log — compare them with the patterns.

The second half: the list is attached by name, and the name is not checked anywhere. A typo means this recipient domain has no patterns at all — and nothing reports it.

What the Hub does. It writes it — in the recipient policy template, attaching the blocking-errors list to all fifteen blocks: fourteen large mailbox providers and the general <domain *>.

The list is shared with Protosender: the same patterns, the same layout. This is part of the agreement on a single configuration format — a node configured by the Hub is readable by both products.

Recommended values

What to set. The value is a list name; the choice is how many lists to keep:

Value When
one common list receivers’ patterns are similar — our case
a list of its own per receiver a large receiver has special responses, and the common rules get in its way
do not write it responses are parsed only by codes, without texts

The third is the vendor default, and it is weaker: receivers use the same codes, while the meaning is in the text.

The syntax and purpose come from the manual, § 3.3.10.101. The link with backoff mode comes from the analysis of the mechanism itself. The breakdown of cases is ours.
Example configuration
# the list is declared separately, and the recipient domain refers to it
<smtp-pattern-list blocking-errors>
</smtp-pattern-list>

<domain $mailru>
    smtp-pattern-list blocking-errors</domain>
The name is not checked anywhere: a typo means this recipient domain has no patterns, and nothing reports it.
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▶

Assuming the patterns work because the line is there

our experience

What it costsReceivers change their response texts. A rule for the previous text stops matching silently: backoff mode does not kick in, messages go at the previous rate, bounces grow.
How to spot itBounces at the receiver grow, while the queue does not go into backoff mode.
How to do it rightCompare the patterns with live response texts from accounting instead of relying on the line being present.

Getting the list name wrong

§ 3.3.10.101

What it costsThe name is not checked anywhere. A typo means this recipient domain has no patterns at all, and no error occurs.
How to spot itOne receiver behaves differently from its neighbors with identical settings.
How to do it rightCompare the name in the attachment line with the name of the declared block.
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-pattern-list <name>
Values
a pattern list name
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and obeys recipient block merging: a narrower block overrides a wider one. A list named in the * block goes to all receivers that have not named their own.
How to check on the node
What needs checking is not the attachment but whether the patterns match live responses:
grep -n 'smtp-pattern-list' /etc/pmta/config
grep -i 'dsnDiag\|smtp;4\|smtp;5' /var/log/pmta/acct-*.csv 2>/dev/null | tail -20
The second command gives live receiver response texts. These are what should be compared with the patterns: a rule that does not match the current text does not trigger and does not report it.
In the Hub
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Tune the pace for a provider