Demo
Demo

Knowledge base

PMTA knowledge base›Configuration block§ 3.3.4

<feedback-loop-processor>

Parsing spam complaints
The only source of the complaint rate

Mailbox providers deliver their users’ complaints as separate messages — each through its own feedback loop program, to the address you registered with them. The block catches these messages and parses them, writing the result as an accounting record of type f.

🔴 There is no other source of the complaint rate. It is visible neither in the conversation nor in bounces: the receiver accepted the message, delivered it, and only then a person clicked “spam.” Without this block, the value by which mailbox providers judge you most strictly is invisible to you.

The condition for it to work is accepting the messages. The block decides the fate of already accepted ones; acceptance is allowed by relay-address, and an MX record pointing to the processor’s address brings the message to the node.

<email-patterns> can be nested in the block — patterns for receivers whose complaints do not arrive in the standard format.

Example configuration
# receiving, parsing and the address registered with mailbox providers
relay-address /^fbl@fbl\./
<feedback-loop-processor>    deliver-matched-email no
    deliver-unmatched-email no
    <address-list>
        address /^fbl@fbl\./
    </address-list>
</feedback-loop-processor>
An MX record for fbl.<domain> pointing to this node is also needed — otherwise complaints will not reach it.
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 complaintsforward-unmatched-toWhere to forward messages not recognized as complaintsdeliver-matched-emailset by the HubWhether to deliver messages recognized as complaintsforward-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