Knowledge base
Returned mail as a telemetry source
Reports that arrive by mail become data
The task. A node whose MX listener accepts bounces and complaints for the domains it sends from.
What it is made of:
- deliver-matched-email in <bounce-processor> — identified bounces are absorbed rather than delivered;
- deliver-unmatched-email — an unidentified message goes further so it can be looked at — this is also the condition for forward-unmatched-to;
- deliver-matched-email in <feedback-loop-processor> — the same split for complaints;
- check-spf-inbound — report authenticity via SPF.
The parts have different scopes. The processors are blocks of their own, and the SPF check belongs to the source and follows source merging.
How they interact. The manual names the forwarding dependency directly: forward-unmatched-to works only with deliver-unmatched-email true. The rejection defaults are described separately, and the trap arises at the junction: by enabling check-spf-inbound for authenticity, you also enable rejection based on the check results — reject-spf-check-fail and reject-spf-check-temperror are true by default.
The main trap is enabling the SPF check without looking at rejections. check-spf-inbound together with the reject-spf-check-fail and reject-spf-check-temperror defaults rejects messages with broken or unavailable SPF: reports from such a provider stop arriving, and a temporary DNS error turns into a rejection at MAIL.
What the Hub does. It applies half of it. The bounce and complaint processors are on the node, and both absorb what they recognize — deliver-matched-email no. But the Hub does not keep what is unrecognized either — it discards it (deliver-unmatched-email no), so there is nowhere to look at a message the processor did not understand; report authenticity is not checked by SPF.
Recommended values
Processor and check lines:
| Line | Default | What to set |
|---|---|---|
| deliver-matched-email, both processors | false | leave false |
| deliver-unmatched-email | true if there is no forward-unmatched-to | true and a mailbox someone reads |
| check-spf-inbound | false | true, but with a decision about rejections |
| reject-spf-check-fail, reject-spf-check-temperror | true | set explicitly |
The lines, defaults and the forwarding dependency come from the manual (§ 3.3.3.1–3.3.3.4, § 3.3.4.2, § 3.3.7.22, § 3.3.7.69–3.3.7.71). The scheme itself is our hypothesis.
Example configuration
<bounce-processor> deliver-matched-email no deliver-unmatched-email yes forward-unmatched-to bounces-review@example.com <address-list> address /^bounce@bounce\./ </address-list> </bounce-processor>
Reports the processor did not recognize will go to the analysis mailbox rather than disappear; the address is for illustration.
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
Check what the node does with unidentified reports:
grep -n -A6 '<bounce-processor\|<feedback-loop-processor' /etc/pmta/config
deliver-unmatched-email no — unidentified messages are discarded, and there is nowhere to look at them.