Demo
Demo

Knowledge base

PMTA knowledge base›Configuration block§ 3.3.3

<bounce-processor>

Parsing asynchronous bounces
Where the real hard bounce rate comes from

Bounces come in two kinds. A synchronous one is stated by the receiver right in the conversation, and it gets into accounting by itself, as a record of type b. An asynchronous one arrives as a message — minutes or hours later — and without this block there is no way to learn about it.

The block catches messages by a nested address list and parses them. What it learns it writes as a record of type rb; what to do with the messages themselves is decided by deliver-matched-email and deliver-unmatched-email.

🔴 Without it bounce statistics are understated. Large mailbox providers often accept a message in the conversation and refuse it later — that is, asynchronously. A hard bounce rate calculated without rb records is lower than the real one, and decisions about list cleaning are made on incomplete data.

The condition for it to work is accepting these messages at all. The address list decides the fate of an already accepted message; acceptance is allowed by a different line, relay-address. Without it, anti-relay will reject the report with a hard bounce before it even arrives.

<email-patterns> can be nested in the block — a set of patterns for receivers whose reports the engine does not understand by itself.

Example configuration
# one line allows receiving, the block handles parsing
relay-address /^bounce@bounce\./
<bounce-processor>    deliver-matched-email no
    deliver-unmatched-email no
    <address-list>
        address /^bounce@bounce\./
    </address-list>
</bounce-processor>
The first line is mandatory: without it the messages will not be accepted at all, and there will be nothing to parse.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
Block directives: 5
Bounces 5
deliver-unmatched-emailset by the HubWhether to deliver messages not recognized as bouncesforward-unmatched-toWhere to forward messages not recognized as bouncesdeliver-matched-emailset by the HubWhether to deliver messages recognized as bouncesforward-errors-toWhere to forward messages on which parsing faileddeliver-emaildeprecatedThe former common delivery switch — a deprecated directive
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.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇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
Receiving inbound mail