Demo
Demo

Knowledge base

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

suppression-lists

<virtual-mta-pool>

Suppression lists shared by all addresses in the pool
in the configuration this is a linesuppression-listsinside the block <virtual-mta-pool>
The same name 2:<source><virtual-mta><virtual-mta-pool>— some of them are other settings, some are the same one
One list for the whole group of addresses

The behavior is the same as for a sending address: the message is accepted, queued and bounced with 5.7.1 (suppressed). Only the scope changes — the line goes to each pool member.

There is only one reason to write it here — not to repeat yourself. A group of addresses that must honor the same list is described with one line instead of repeating it for each.

The override is complete. A member that has its own line does not add to the pool line but replaces it: lists do not add up. For a member to honor both the common list and its own, both have to be listed.

The main trap is expecting the lists to add up. A member’s own line replaces the pool line entirely. By giving an address a list “of its own,” you silently turn off the common one for it — and this is discovered through messages that went out, not through a configuration error.
What the Hub does. It does not write it: suppression works before the node. The line is, however, an example of why a pool is worth using as a scope: today the Hub repeats common rules for each sending address separately, and suppression lists would be repeated in exactly the same way.
Recommended values

The value is list names separated by commas, as for a sending address. Only one thing is decided here — where to keep the list:

Where Who gets it Watch out
in the pool all members a member’s own line will replace it entirely
on a member only that member the pool line stops applying to it
in both places only its own applies to the member all the needed lists have to be listed
Inheritance by members comes from the manual (§ 3.3.13). The “replaces rather than adds” rule is common to directive inheritance, and here it bites hardest.
Example configuration
# all addresses in the group honor the list — with one line
<virtual-mta-pool warmup-wave-3>
    suppression-lists complaints,traps    virtual-mta mta1
    virtual-mta mta2
</virtual-mta-pool>
Both members will get both lists. If mta1 gets its own line suppression-lists own, only own will remain for it — complaints and traps will stop being checked.
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▶

Giving a member its own list on top of the pool one

§ 3.3.13

What it costsThe member’s line replaces the pool line entirely. The common list stops being checked for this address, and messages that should not have gone out go out.
How to spot itOne address in the group sends to those the others suppress.
How to do it rightList all the needed lists on the member — both the common ones and its own.

Expecting a refusal at submission

§ 11.15.2

What it costsAt the pool and sending address level there is no choice: the message is accepted and bounced later. The sender learns from a report, not right away.
How to spot itSubmission goes through without errors, and the bounces come later.
How to do it rightIf the signal is needed at submission, hang the list on <source> and set accept-invalid-recipients no.
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 <see-reference>
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-pool>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The pool is the middle of three levels. The line goes to each member, and a member’s own line overrides it entirely. The check in <source> is separate and independent: there suppression can trigger earlier and turn into a refusal at submission.
⇄

Related directives

2 relations

Same name in other blocks

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

Applies to

A group of sending addresses with traffic sharesOne of the seven directives a pool hands out to its members; a member’s own line overrides it. § 3.3.13.9

How to check on the node
What actually applies to a member is visible from the refusal — its text contains the name of the list that matched:
pmtaacctfind --output csv[rcpt,vmta,dsnDiag] /var/log/pmta/acct-*.csv
If the pool list name does not appear in refusals, yet the member still bounces messages, it has its own line — which replaced the pool line. Look in the sending address’s own block.
◇

What else to read

3 articles

◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Warm-up built into the engineA warmed-up address hands the first N messages of the day for each receiver to its cold partner; the partner sends them itself and builds history.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation
Neighboring settings of the block <virtual-mta-pool>:virtual-mtadomain-keymax-smtp-msg-ratemax-smtp-outinclude-headers-fromAll 9 directives of the block →