Demo
Demo

Knowledge base

PMTA knowledge base›Block <feedback-loop-processor>›Directive§ 3.3.4.2

deliver-matched-email

<feedback-loop-processor>set by the Hub

Whether to deliver messages recognized as complaints
in the configuration this is a linedeliver-matched-email falseinside the block <feedback-loop-processor>
The same name 1:<bounce-processor><feedback-loop-processor>— some of them are other settings, some are the same one
The fate of a message after parsing

The processor recognized the message, extracted data from it and wrote it to accounting as an f record. This line decides what to do with the message itself. The default is false, that is, discard.

The data has already been saved by then. Discarding the message does not mean losing the information: it went to accounting before this decision. The line is about the paper, not the content.

Delivering makes sense in two cases. The first is when the processor’s address is real and a person wants to see the complaints with their own eyes. The second is when your own program runs alongside and parses the same messages in its own way.

In the usual setup there is nowhere to deliver to: an address like fbl@fbl.<domain> is created for the processor, there is no mailbox behind it, and true here would mean an attempt to deliver into nowhere.

The main trap is enabling delivery to an address without a mailbox. The message will go into delivery, fail to find a recipient and generate its own bounce — which will come to the same address and land in the processor again. The loop will end on the hop counter with a routing error.
What the Hub does. It writes no, that is, recognized mail is discarded after being written to accounting.

Our processor catches fbl@fbl.<domain>. There are no mailboxes behind these addresses: they exist for receiving and parsing, not for reading. The data goes to the Hub via webhook as f records — that is enough.

Recommended values

The answer depends on whether there is a mailbox behind the address:

Value When
no (default) the address was created for the processor, there is no mailbox
yes the mailbox is real and is read

Data gets into accounting with any value.

The false default and the fact that with this value the message is discarded come from the manual (§ 3.3.4.2). The warning about the loop is ours.
Example configuration
# the address was created for the processor: nowhere to deliver
<feedback-loop-processor>
    deliver-matched-email no    deliver-unmatched-email no
    <address-list>
        address /^fbl@fbl\./
    </address-list>
</feedback-loop-processor>
The data from recognized messages has already been written to accounting: discarding the message does not affect it.
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 ends1 mistake▶

Enabling delivery to an address with no mailbox behind it

our experience

What it costsThe message will go into delivery, fail to find a recipient and generate its own bounce. That bounce will come to the same address and land in the processor again — until the hop counter fires.
How to spot itRouting errors on the processor’s addresses in the log.
How to do it rightKeep no where there is no mailbox; the data is in accounting anyway.
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.
Reference data
Syntax
deliver-matched-email <boolean>
Values
yes | no | true | false
Default
false § 3.3.4.2
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<feedback-loop-processor>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside its <feedback-loop-processor> and decides the fate of messages caught by its address list. The neighboring processor has its own such line.
⇄

Related directives

2 relations

Same name in other blocks

deliver-matched-email<bounce-processor>The same line in the second processor: they are built the same way. § 3.3.4.2

Applies to

Two inbound report processors and what to do with themThe mechanism in which this line is one of four decisions about a message’s fate. § 3.3.4.2

Referenced from

deliver-email<feedback-loop-processor>Half of the replacement: the decision about recognized messages. § 3.3.4.3

How to check on the node
Check it by accounting: records must appear regardless of the message’s fate:
cut -d, -f1 /var/log/pmta/acct-*.csv | sort | uniq -c
f records mean parsing works. Their absence means messages do not reach the processor or are not recognized by it; the message’s fate after parsing has nothing to do with it.
◇

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
Managed at
Analytics → Node accounting
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Receiving inbound mail
Neighboring settings of the block <feedback-loop-processor>:deliver-unmatched-emailforward-unmatched-toforward-errors-todeliver-emailAll 5 directives of the block →