Demo
Demo

Knowledge base

PMTA knowledge base›Block <virtual-mta>›Directive§ 3.3.12.15

suppression-lists

<virtual-mta>

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

The line names lists separated by commas, as in a source. One thing changes, and it is the main one: there is no choice between a refusal at submission and a bounced message here. The message is accepted, queued and bounced with a 5.7.1 (suppressed) record, whose text contains the list name.

Why. The sending address is chosen after the message is received — at submission the node does not yet know which stream it will go through. There is simply nowhere to check the list before that choice.

Hence the scope of use. What belongs here is what relates to the address, not the sender: recipients who must not be written to from this particular address. General suppression is better hung on the source — there it turns into a refusal.

This is an independent, second check. A list in the source and a list here do not add up and do not replace each other: either can trigger.

The main trap is treating this as the same thing as in a source. The line looks the same and behaves differently: the sender learns nothing at submission, the message travels all the way to the queue, and the result has to be fished out of bounces without confusing it with a real recipient refusal.
What the Hub does. It does not write it — neither here nor in the source: suppression works before the node, with its own list in the database. If lists on the node are ever needed, they should be hung on the source: a refusal at submission is more honest and cheaper than a bounce that then has to be classified correctly.
Recommended values

The value is list names separated by commas, as in a source. The difference is where to hang what:

What we suppress Where to hang it Why
the general blocklist <source> there it is a refusal at submission
recipients who must not get mail from this address here tied to the address, not to the sender
the same for a group of addresses <virtual-mta-pool> every member will get it
The absence of a choice and the refusal code come from the manual (§ 11.15.2). The “what to hang where” breakdown is ours.
Example configuration
# recipients who must not be written to from this particular address
<virtual-mta shop-example-com>
    smtp-source-host 203.0.113.10 shop.example.com
    suppression-lists no-shop-mail</virtual-mta>
A message to such a recipient will be accepted, queued and bounced with 5.7.1 (suppressed). The sender will not find out at submission — if that matters, the list is hung on <source>.
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▶

Hanging the general blocklist here

§ 11.15.2

What it costsEvery suppressed message travels all the way to the queue and turns into a bounce. At volume this is extra work for the node and a stream of bounces that the classifier has to distinguish from real ones.
How to spot itMany 5.7.1 (suppressed) bounces, even though the messages were never supposed to be sent.
How to do it rightHang general suppression on <source> and put accept-invalid-recipients no next to it — then it is a refusal at submission.

Blaming such bounces on the recipient

our experience

What it costsThe refusal is born on our own node and says nothing about the recipient. A classifier that adds it to the blocklist suppresses the address twice, and for a nonexistent reason.
How to spot itAddresses from the suppression list start landing in the general blocklist as well, as “bounced.”
How to do it rightDistinguish internal refusals by code and text: x-pmta;recipient is in suppression list is our own decision, not a receiver response.
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 <name>
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
<virtual-mta>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The line is inherited in the usual order for sending addresses: written in <virtual-mta-pool>, it goes to each member, and a member’s own line overrides the pool line entirely — lists do not add up. The manual lists it among the directives supported at the pool level. The check in <source> is separate and independent.
⇄

Related directives

3 relations

Does not work without

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

Same name in other blocks

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

Applies to

The sending address — what it is made ofOne of the sending address settings: whose messages it will not send. § 3.3.12.15

Referenced from

suppression-lists<virtual-mta-pool>The manual gives the definition for a sending address; here is only what writing it at the pool level changes. § 3.3.12.15

How to check on the node
This suppression can be told apart from the source one by the refusal code:
pmtaacctfind --output csv[rcpt,vmta,dsnDiag] /var/log/pmta/acct-*.csv
5.7.1 (suppressed) means a sending address or pool list matched; 5.7.1 (delivery not authorized) means a source list. In both cases the list name is in the refusal text.
◇

What else to read

3 articles

◇Address lists — named and unnamedA list of addresses, domains, patterns or hashes; a named one is attached by directives such as suppression, an unnamed one lives inside an inbound mail processor.◇Configuration through the API and the file do not reconcileObjects created through the configuration interface cannot be edited in the file: two sources of truth about the configuration do not reconcile.◇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.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Address suppression
Neighboring settings of the block <virtual-mta>:host-namedomain-keysmtp-source-hostsmtp-proxy-source-hostproxy-protocolAll 15 directives of the block →