Demo
Demo

Knowledge base

PMTA knowledge base›Monitor screen§ 11.1.8

Bounces according to the service

Bounce Report Display
Bounces in someone else’s classification

The SparkPost Signals report on bounces for a selected period.

The classification here is SparkPost’s own: the manual explicitly warns that it does not match PowerMTA bounce categories. This is a third classification alongside the engine’s categories and our split into hard and soft.

The report lives in the SparkPost application, not in the node’s monitor: the node only sends accounting data there and reads nothing back. Access to the report is through a SparkPost account, not http-access.

The main trap is mapping report lines to the engine’s categories one to one. SparkPost classification codes and PowerMTA categories are different vocabularies: the same bounce reason can land in them differently, and the manual gives no direct mapping.
What the Hub does. It does not use it: the Hub does not write a <signals> block, and no data goes from the nodes to SparkPost. The Hub analyzes bounces itself — by the engine’s categories from accounting and by its own split into hard and soft.
Recommended values

Where to look for what:

Question Where
bounces in SparkPost’s classification here
bounces in the engine’s categories node accounting, the bounceCat field
sending metrics as a whole the Signals summary
The report’s purpose and the classification mismatch come from the manual (§ 11.1.8); one-way data sending is § 11.1. The split of questions is ours.
Example configuration
# without a signals block no data goes to the service and the report is empty
<signals>
    api-key 0123456789abcdef012345678901234567890123</signals>
The key is 40 hexadecimal characters issued by SparkPost; without the api-key line the engine with a <signals> block will not start.
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

1 relation

Where you can see it

The vendor's analytics — and what leaves the node for itThe mechanism that is visible here. § 11.1.8

Referenced from

The bounce category in accounting — configurable, not vendor-fixedA third way to sort bounces into buckets — alongside the vendor defaults and our own rules. inference

How to check on the node
Check whether data goes to the service at all:
grep -n -A3 '<signals>' /etc/pmta/config
grep -n 'enable-signals' /etc/pmta/config
No block means no report. enable-signals false on an address or pool turns off data sending only for them.
◇

What else to read

3 articles

◇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.◇A return address with the recipient written into itThe bounce arrives at a unique address, and there is no need to parse its content.◇What to return in a bounce reportWhat to enclose in a bounce report: the whole message or only its headers.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Bounce classification