Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 13.7

Complaints parsed by the node — and they are parsed second

critical

feedback loop processor
The order of processors decides what a message turns out to be

A complaint arrives as an ordinary message, and before it becomes a complaint it has to be recognized. A separate processor does this: mail to addresses from the configured list is parsed as a complaint report rather than delivered.

The order of processors matters. The bounce processor goes first, the complaint processor second. A message recognized by the first will not reach the second.

Hence the consequence: a complaint that looks like a bounce report in form will be parsed as a bounce. Their forms are related — both are service reports about a message — and a match is not rare.

What is not recognized does not vanish. Separate settings decide whether to deliver unrecognized mail the usual way or forward it to a given address.

The parsing result goes into accounting as a separate record type — that is what the complaint rate is calculated from.

The main trap is calculating the complaint rate from one source. Some complaints are recognized by the bounce processor and go into accounting as bounces; some arrive in a form neither recognizes and end up in regular delivery or forwarding. A number taken only from complaint records is always understated — the only question is by how much.
What the Hub does. It configures it: the node has a <feedback-loop-processor> that catches complaints sent to fbl@fbl.<domain>. Recognized complaints are not forwarded further but become accounting records of type f and go via webhook to the Hub — where they are counted in the fleet panels, in the health score and in the warm-up counters.

There are two conditions outside the node: an MX record for fbl.<domain> pointing to the node (it is created by hand), and a feedback loop with the provider registered for this address. Role addresses (abuse@, postmaster@, dmarc@) are accepted by the node with a separate rule, but they are not parsed as complaint reports: the processor catches only fbl@fbl.<domain>.

Recommended values

What is needed for complaints to be counted on the node:

What Why
a list of complaint addresses it is how the processor recognizes its mail
a complaint processor the one that parses the report
a decision about unrecognized mail deliver the usual way or forward
understanding the order the bounce processor goes first and will take anything similar

Unrecognized mail is better forwarded than delivered. Forwarding to a live mailbox shows what the processor did not understand — and it is the only way to learn about a complaint format it misses.

Compare the complaint rate with two sources. The node’s accounting and the provider’s data always diverge; the divergence is the measure of how much parsing misses.

The advice about forwarding unrecognized mail and comparing two sources is ours. From the manual here are the recognition mechanism by address list, the order of processors and the settings for handling unrecognized mail.
Example configuration
# the order of processors is set by the engine: bounces, then complaints
<feedback-loop-processor>
    forward-unmatched-to fbl-review@example.net    deliver-unmatched-email false
</feedback-loop-processor>
The highlighted line is the way to see what the processor did not understand. Without it unrecognized complaints disappear, and there is no way to learn they existed.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends3 mistakes▶

Calculating the complaint rate from one source

§ 13

What it costsSome complaints are recognized by the bounce processor and go into accounting as bounces; some are not recognized at all. The number from complaint records is always understated.
How to spot itThe complaint rate on the node is noticeably lower than what the provider shows.
How to do it rightCompare two sources. The divergence is the measure of how much parsing misses.

Leaving unrecognized mail on regular delivery

§ 13

What it costsA complaint in a form the processor did not understand goes the usual way — that is, nowhere, if there is no mailbox behind the address. There is then no way to learn that such a form exists.
How to spot itThe processor is configured, there are few complaint records, and noticeably more messages arrive at the address.
How to do it rightForward unrecognized mail to a live mailbox and look at what ends up there.

Expecting the complaint processor to take everything from the complaint address

§ 13

What it costsThe bounce processor runs earlier and takes what it recognizes. A complaint that looks like a bounce report in form will be parsed as a bounce — and will not appear in the complaint records.
How to spot itBounce records come from addresses complaints are sent to.
How to do it rightRemember the order. When the numbers diverge, look at the bounce records: some complaints will be there.
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.
Inheritance
The processor has no inheritance: it is either described in the configuration or not. What is inherited is the address list by which it recognizes its mail — and the order of processors is set by the engine, not by a setting: bounces are always parsed first.
⇄

Related entries

3 relations

Depends on

Parsing bounces that arrive as messagesThe bounce processor goes first and takes everything it recognizes as a bounce. § 13.7

Works together with

The complaint format of one large receiverOne of the report types this processor parses. § 13.7.1

Where you can see it

ComplaintThe accounting record a parsed complaint ends up in. § 13.7

Referenced from

Reports the engine does not understand by itselfMost often it is complaints, not bounces, that arrive non-standard. § 13.10Two inbound report processors and what to do with themThe second of the two processors: complaints from mailbox provider users. § 13.7

How to check on the node
Check not the setting but what got into accounting:
grep -n -A5 '^<feedback-loop-processor' /etc/pmta/config
grep -c '^f,' /var/log/pmta/acct-*.csv
The second command counts complaint records in accounting. Zero with a configured processor means messages either do not arrive or are recognized earlier by the bounce processor.
◇

What else to read

3 articles

◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇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
Troubleshoot deliverability · Address warm-up · Address suppression
Priority
critical