Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 11.15

Two attachment points — and two different behaviors

critical

address suppression lists
Where the list is attached decides when the sender finds out

The same list means different things depending on where it is attached, and the difference lies in the moment the sender finds out.

In a source the behavior is set by the neighboring accept-invalid-recipients line: no — the recipient is rejected right at the RCPT command, and the submitting program learns immediately; yes — the message is accepted and bounced later, with a 5.7.1 (delivery not authorized) bounce record.

In a sending address or pool there is no choice: the message is always accepted, queued and bounced — 5.7.1 (suppressed).

Several lists can be attached, comma-separated, at both points. And for batch submission from a directory the rule is the same, except that delivery confirmation decides instead of accept-invalid-recipients.

The vendor advises no more than five hundred patterns in one list. This is a practical ceiling, and it determines what can go here: not the whole blocklist but its special part.

The main trap. Attaching to a sending address looks more convenient (“suppression right where the address is”), but it is actually the worse of the two options: the sender learns nothing at submission, the message travels all the way to the queue and turns into a bounce that then has to be classified correctly. A refusal at submission is more honest and cheaper.
What the Hub does. It does not use it: our suppression works before the node. The Hub keeps its blocklist in its database, shared with the sending platform (unsubscribed in a warm-up message — will not get the live campaign, and vice versa), and does not hand it to the node. Lists on the node would be a second line of defense for when a message gets into PowerMTA bypassing the Hub — but the ceiling of five hundred patterns makes them unsuitable for a full blocklist.
Recommended values

The mechanism has no values of its own: the value is list names, set by suppression-lists. The choice here is the attachment point:

Where to attach When the sender finds out When to do this
<source> with accept-invalid-recipients no immediately, via a refusal at RCPT your own submission: the error is visible and can be fixed
<source> with accept-invalid-recipients yes later, via a bounce record outside submission that does not expect an RCPT refusal
<virtual-mta> or a pool always later, via a bounce record there is no choice — that is how it works

What to put here with a ceiling of 500 patterns: not the whole blocklist, but what must not go out under any circumstances — complainers, spam traps, addresses removed at a client’s request.

Both refusal codes, the dependence on accept-invalid-recipients and the advice about 500 patterns come from the manual (§ 11.15). What to put in the list is ours.
Example configuration
# in a source — a refusal at submission; in a sending address — a refusal later
<address-list suppression1>
    address /^complaints\+/
</address-list>

<source 10.0.0.0/24>
    accept-invalid-recipients no
    suppression-lists suppression1</source>
With accept-invalid-recipients no the submitting program will get a refusal right at the RCPT command and can do something about it. Move the suppression line into the sending address block — and the same check turns into a bounce the sender learns about from a report.
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▶

Putting the whole blocklist into a list

§ 11.15

What it costsThe vendor advises no more than five hundred patterns in one list. A real blocklist is tens or hundreds of thousands of addresses; with such a configuration the check becomes expensive and the file itself unmanageable.
How to spot itThe configuration grows, applying it slows down, and editing the list by hand is impossible.
How to do it rightKeep the full blocklist where it belongs — in the sending system’s database. Leave on the node a short list of what must not go out under any circumstances.

Attaching to a sending address while expecting a refusal at submission

§ 11.15.1

What it costsIn a sending address and a pool there is no choice: the message is always accepted and bounced later. The submitting program considers the message sent, while the recipient does not receive it.
How to spot itReports have 5.7.1 (suppressed) bounces, while submission goes through without a single error.
How to do it rightAttach to the source and set accept-invalid-recipients no — then the sender learns immediately.

Forgetting about accept-invalid-recipients

§ 11.15.1

What it costsIn a source it is exactly this line that decides the behavior. With invalid recipient acceptance on, suppression still works, but turns into bounces instead of refusals at submission — and for whoever reads the reports those are different things.
How to spot itYou expected a refusal at RCPT but get bounce records.
How to do it rightSet both lines together: the suppression list and accept-invalid-recipients no. This is one setting made of two.
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.
Inheritance
The mechanism itself has no inheritance: the directive that enables it is inherited. In <source> it merges by the source rule — a narrower block overrides a wider one; in a pool it goes to the members, and a member’s own line overrides the pool one. The attachment points do not add up: a list in a source and a list in a sending address are two different checks, and either can fire.
⇄

Related entries

3 relations

Depends on

accept-invalid-recipients<source>In a source it is exactly this line that decides whether to refuse at submission or accept and bounce the message later. § 11.15.1

Applies to

Address lists — named and unnamedThe address list itself; suppression is only one of its three uses. § 11.15

Where you can see it

Address lists through the configuration APILists are edited over HTTP, without editing the configuration and without a reload — that is what makes the mechanism interesting. § 11.15

Referenced from

Mail merge via SMTP extensionsA related mechanism: they work together. § 11.15.1

How to check on the node
That suppression fired is visible in the refusal — by the code and the text, which names the list:
pmtaacctfind --output csv[rcpt,dsnStatus,dsnDiag] /var/log/pmta/acct-*.csv
5.7.1 (delivery not authorized) — a source list fired with invalid recipient acceptance on; 5.7.1 (suppressed) — a sending address or pool list. In both cases the refusal text contains the list name, and it shows which one fired.
◇

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.◇A license for a fleet, not for a serverThe license is not bound to a server: it is installed on as many machines as the instance limit allows, and the nodes send volume statistics to the vendor every hour.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Address suppression · Sender isolation
Priority
critical