Demo
Demo

Knowledge base

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

forward-unmatched-to

<feedback-loop-processor>

Where to forward messages not recognized as complaints
in the configuration this is a lineforward-unmatched-toinside 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
What to do with what the processor did not understand

The processor parses incoming messages and recognizes complaints among them. The fate of what it did not recognize is decided by two lines, and this one answers “forward it to a live person.” The line is repeatable: there can be several addresses.

🔴 It is not enough on its own. The manual says it directly: with forwarding set, deliver-unmatched-email must be true, otherwise the message is discarded before it reaches forwarding. The two lines work only as a pair.

Why it is needed. The processor catches messages by an address list but recognizes only what looks like a spam complaint. Everything else arriving at the same address — replies from people, non-standard reports, messages from services — is garbage to it. Without forwarding this garbage disappears silently, and there is no way to learn it was there.

There is no default: if it is not set, no forwarding happens.

The main trap is setting forwarding while leaving delivery of unrecognized mail off. There will be no error, and no messages either: they are discarded before forwarding. This is the quietest possible error in this block.
What the Hub does. It does not write it — and this is worth revisiting.

In our configuration the processor catches fbl@fbl.<domain> — the address we register with mailbox providers in their feedback programs.

🔴 We have deliver-unmatched-email no, that is, everything unrecognized is discarded. For feedback-loop-processor this means that messages arriving at its addresses and not looking like a spam complaint disappear without a trace.

Recommended values

It works only as a pair, and the pair is mandatory:

What Value
this line the address of a live mailbox
deliver-unmatched-email must be true

The mailbox must be real and read: the point of the line is for someone to see what arrived.

Repeatability and the requirement that delivery of unrecognized mail be allowed come from the manual (§ 3.3.4.4, § 3.3.4.1). The analysis of what exactly is lost is ours.
Example configuration
# the two lines work only together
<feedback-loop-processor>
    deliver-unmatched-email true
    forward-unmatched-to postmaster@example.com    <address-list>
        address /^fbl@fbl/
    </address-list>
</feedback-loop-processor>
Remove the first line — and forwarding will stop working without saying so.
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 ends2 mistakes▶

Setting forwarding while delivery of unrecognized mail is off

§ 3.3.4.1

What it costsThe message is discarded before it reaches forwarding. No error, no message — and this can be understood only from the manual.
How to spot itThe line is set, and the forwarding mailbox is empty.
How to do it rightSet deliver-unmatched-email to true.

Forwarding to a mailbox nobody reads

our experience

What it costsThe point of the line is for a person to see what arrived. A mailbox without a reader differs from a discarded message only in where it lies.
How to spot itThe forwarding mailbox has not been opened for months.
How to do it rightAssign a reader or go through the mailbox contents on a schedule.
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
forward-unmatched-to <email-address>
Values
an email address; the line is repeatable
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<feedback-loop-processor>
How many times
may be repeated
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 and its own list.
⇄

Related directives

2 relations

Same name in other blocks

forward-unmatched-to<bounce-processor>The same line in the second processor: they are built the same way. § 3.3.4.4

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.4

How to check on the node
There is one check — send the processor’s address a message it certainly will not recognize and see whether it reached the forwarding mailbox:
grep -i "forward\|unmatched" /var/log/pmta/log | tail -20
The message should end up in the forwarding mailbox. If it did not, check deliver-unmatched-email: most likely it is off, and the message was discarded.
◇

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
Neighboring settings of the block <feedback-loop-processor>:deliver-unmatched-emaildeliver-matched-emailforward-errors-todeliver-emailAll 5 directives of the block →