Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 13.6

Parsing bounces that arrive as messages

critical

bounce processor
It works first, before the complaint processor

Some bounces arrive not in the conversation with the receiving server but later, as a separate message. The <bounce-processor> processor recognizes such messages at the addresses on its list and writes rb accounting records — a bounce — and rs — other status reports.

A parsed message can be discarded or delivered onward: deliver-matched-email and deliver-unmatched-email decide the fate of recognized and unrecognized messages. Changing the list requires a service restart.

Order matters: this processor handles mail before the complaint processor. If an address matches both and unrecognized mail is not delivered, the complaint never reaches <feedback-loop-processor> — the address lists are better kept disjoint.

The main trap is overlapping the lists with the complaint processor. The bounce processor goes first: an address on both lists goes to it, and a complaint that arrives at that address never becomes an f record.
What the Hub does. It is configured: the processor listens on bounce@bounce.<domain> and the role addresses dmarc@, postmaster@, abuse@, both delivery options are off — what is recognized becomes rb records, the rest is discarded. The rb records go to the Hub through the accounting webhook; the return address bounce@bounce.<domain> is enabled with a checkbox in the configuration generator.
Recommended values

Processor settings:

Setting What it decides
address list which messages to parse as reports
deliver-matched-email whether to deliver recognized ones; no by default
deliver-unmatched-email whether to deliver unrecognized ones; yes by default

For precise accounting the manual advises a unique return address per message rather than a shared bounce@.

The rb and rs records, the two switches with their defaults, the restart and the order of processors come from the manual (§ 13.6, § 13.7). The trap analysis is ours.
Example configuration
<bounce-processor>
    deliver-matched-email no
    deliver-unmatched-email no
    <address-list>
        address /^bounce@bounce\./    </address-list>
</bounce-processor>
This is how the Hub node is configured: recognized reports become rb records, everything else is discarded.
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.
⇄

Related entries

3 relations

Conflicts with

Complaints parsed by the node — and they are parsed secondA related mechanism: they work together. § 13.7

Works together with

A return address with the recipient written into itA related mechanism: they work together. inference

Where you can see it

Parsed bounce from outsideThe accounting record in which the result is visible. § 13.6

Referenced from

Two inbound report processors and what to do with themThe first of the two processors and its role in delivery analysis. § 13.6

How to check on the node
Check that reports are being parsed:
grep -h '^rb,' /var/log/pmta/acct*.csv | tail -5
No rb lines while bounces are coming in — check the MX of the bounce. subdomain and the messages’ return address.
◇

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.◇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.◇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.

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