Demo
Demo

Knowledge base

PMTA knowledge base›Recipe

Deciding “hard or soft” where the reply arrived

Removing the interpretation step between a bounce and a decision

The task. A bounce must be recognized as permanent or temporary before anything reacts to it. When the engine’s category is translated into your own after the record is received, there are two classifiers in a row, and it is the translation that breaks.

What it is made of:

  • bounce-category-patterns — assigns your own category names by the receiver’s words;
  • <smtp-pattern-list> — the same matching mechanism, but for the queue’s reaction rather than for a label;
  • /config/address-lists — where a confirmed permanent bounce goes, without editing files.

The parts have different scopes. An unnamed pattern block is checked before the bundled patterns, and a named one attached to the recipient — before both. Suppression lists are attached to a source or a sending address (suppression-lists).

How they interact. The chain is classification, decision, suppression. Moving classification to the node puts into the record a category already stated in your own words, and the suppression rule reads the field directly. The caveat is durability: the category is set at the moment of recording, and changing the patterns does not repaint the past, so the reply text is worth keeping next to the category.

The main trap is expecting new patterns to repaint past bounces. The category is written into the record at the moment of the bounce: a corrected pattern works only going forward, and old records keep the previous category.
What the Hub does. It applies half of it. The unnamed <bounce-category-patterns> is in the policies template, but its categories are the vendor’s — spam-related, virus-related and the like — not our “hard” and “soft”: the Hub tells a permanent bounce from a temporary one itself, after the record is received. smtp-pattern-list blocking-errors is set for the reaction, and there are no suppression lists on the node — suppression lives in the Hub’s database.
Recommended values

Three steps and where each lives:

Step With what What remains
classification bounce-category-patterns bounceCat with your own name
queue reaction <smtp-pattern-list> a switch to backoff mode
suppression /config/address-lists the address in a list without editing files
The pattern check order, custom category names, the queue reaction and list operations come from the manual (§ 11.7, § 3.3.10.73, § 3.3.15, § 8.3.2). The scheme itself is our hypothesis.
Example configuration
<bounce-category-patterns>
    rcpt-to /invalid recipient/ bad-mailbox    /mailbox +(is +)?full/ quota-issues
</bounce-category-patterns>
Based on the manual’s example: rcpt-to limits the pattern to replies to the recipient command; category names can be your own.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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.
How to check on the node
Look at the category patterns in effect on the node:
grep -rn -A6 '<bounce-category-patterns' /etc/pmta/
An unnamed block is checked before the bundled patterns, so your own rule in it overrides the engine’s category.