Demo
Demo

Knowledge base

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

suppression-lists

<source>

Suppression lists for messages from this source
in the configuration this is a linesuppression-listsinside the block <source>
The same name 2:<source><virtual-mta><virtual-mta-pool>— some of them are other settings, some are the same one
Suppression at the input, not at the output

The line names one or more declared lists — separated by commas. A recipient on at least one of them does not make it to sending.

When exactly the sender finds out is decided by the neighboring line accept-invalid-recipients. With no the recipient is rejected right at the RCPT command — the submitting program gets a refusal and can react to it. With yes the message is accepted and later bounced with a 5.7.1 (delivery not authorized) record, whose text contains the name of the list that matched.

Attaching in the source is the better of the two points. The same line exists in <virtual-mta> and in a pool, but there is no choice there: the message is always accepted and bounced later. Here you can refuse honestly and immediately.

There can be several lists — all of them are checked, and a match in any one is enough.

The main trap is one line instead of two. Suppression attached without accept-invalid-recipients no works, but it turns a refusal into a bounced message: submission goes through without errors, the sender considers the message accepted, and it has to be sorted out from reports.
What the Hub does. It does not write it: the Hub keeps the blocklist in its own database, shared with the sending platform, and checks it before the node — someone who unsubscribed from a warm-up message will not get a production mailing, and vice versa. Lists on the node would be a second line of defense for submission that bypasses the Hub, but the ceiling of five hundred patterns makes them unsuitable for a full blocklist: only what must never go out under any circumstances would fit here.
Recommended values

The value is list names separated by commas. This is configured with a pair of lines, and the second matters more than the first:

accept-invalid-recipients What happens Who it suits
no refusal at the RCPT command, the sender knows right away your own submission: the error is visible and can be fixed
yes the message is accepted and bounced later someone else’s submission that is not designed to handle an RCPT refusal

What to put in the lists. Not the whole blocklist — the vendor advises no more than five hundred patterns — but complainers, spam traps and addresses whose suppression the client requires.

The dependence on accept-invalid-recipients, the refusal code and the advice about 500 patterns come from the manual (§ 11.15.1). What to put in the list is ours.
Example configuration
# two lines — one setting: the list and the refusal method
<address-list suppression1>
    address /^complaints\+/
</address-list>

<source 10.0.0.0/24>
    accept-invalid-recipients no
    suppression-lists suppression1,suppression2</source>
There are two lists here, and both are checked. With accept-invalid-recipients no the submitting program will get a refusal right at RCPT; remove that line — and the same suppression turns into bounced messages.
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▶

Attaching a list without accept-invalid-recipients

§ 11.15.1

What it costsSuppression works, but the sender learns about it from a report, not at submission. For your own submission this is a lost signal: an error that could have been fixed right away has to be fished out of bounces.
How to spot itSubmission goes through without errors, and reports show 5.7.1 bounces.
How to do it rightPut both lines together. This is one setting written in two places of one block.

Putting the whole blocklist into a list

§ 11.15

What it costsThe vendor advises no more than five hundred patterns. A real blocklist is tens of thousands of addresses; such a configuration becomes unmanageable, and the check becomes expensive.
How to spot itThe configuration file keeps growing, and applying it slows down.
How to do it rightKeep the full list in the sending system’s database, and on the node a short list of what must never go out.

Adding a list to a narrow block and expecting the lists to add up

§ 3.3.7

What it costsA narrower source block overrides the value entirely. The wide block’s lists stop being checked for this subnet all at once.
How to spot itAfter a “specific” list is added, the common one stops working.
How to do it rightList all the needed lists in the narrow block, not only the new 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
suppression-lists <list>
Values
names of declared address lists separated by commas
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 wider one. It overrides entirely — the narrow block’s lists are not added to the wide block’s lists but replace them. The same line exists in <virtual-mta> and in a pool; that is a second, independent check point, not a continuation of this one.
⇄

Related directives

2 relations

Does not work without

Address lists — named and unnamedThe line refers to lists by name; the lists themselves are declared separately. § 3.3.7.41

Works together with

allowed-sender-lists<source>A neighboring line using the same lists, only about senders rather than recipients. § 3.3.7.43

Referenced from

suppression-lists<virtual-mta>The same line in a source — there suppression can be turned into an honest refusal at submission. § 3.3.12.15

How to check on the node
Suppression that triggered is visible from the refusal — its text contains the list name:
pmtaacctfind --output csv[rcpt,dsnStatus,dsnDiag] /var/log/pmta/acct-*.csv
5.7.1 (delivery not authorized) means the source list matched with accepting invalid recipients enabled. If there are no records at all while messages go out, check whether the right <source> block matched the submission address: the narrowest one overrides.
◇

What else to read

3 articles

◇The bounce category in accounting — configurable, not vendor-fixedThe bounceCat string in every accounting record comes from a pattern list that can be extended with your own rules and your own category names.◇Parsing bounces that arrive as messagesBounce reports that arrive as messages are parsed by a separate processor — and it runs before the complaint processor.◇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.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Bounce classification · Address suppression
Neighboring settings of the block <source>:smtp-serviceretain-x-dkim-keyprocess-x-virtual-mtadefault-virtual-mtaprocess-x-dkim-keyAll 74 directives of the block →