Demo
Demo

Knowledge base

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

deliver-unmatched-email

<feedback-loop-processor>set by the Hub

Whether to deliver messages not recognized as complaints
in the configuration this is a linedeliver-unmatched-email true if forward-unmatched-to is not specifiedinside 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 unrelated mail

The processor catches messages by an address list but recognizes only complaints among them. This line decides what to do with the rest. The default is true, that is, deliver as regular mail.

🔴 The value false means “discard silently.” No refusal to the sender, no accounting record: the message simply disappears. For an address with no mailbox behind it this is sensible — but for an address people or services write to, it is a loss.

And it is also the condition for forwarding. The manual says it directly: with forward-unmatched-to set, this line must be true — otherwise the message is discarded before forwarding, and the forwarding address does not work.

Hence three possible outcomes for a message that was not understood: deliver (by default), discard (false without forwarding), forward (true plus a forwarding address).

The main trap is discarding what was expected. The processor’s address receives not only what it was set up for: non-standard reports, replies from people, messages from services. With the value false all of this disappears, and there is no way to learn about the loss — no record is left anywhere.
What the Hub does. It writes no, that is, unrecognized mail is discarded.

Our processor catches fbl@fbl.<domain>.

🔴 And for bounces this is worth revisiting. We accept role addresses on the same processor — dmarc@, postmaster@, abuse@. The bounce processor does not recognize bounces in them, and with no the daily DMARC aggregate reports we ourselves requested with the rua record are discarded. Along with them go messages from complaint services to abuse@ and everything written to postmaster@. The cure is a pair: true plus forward-unmatched-to to a live mailbox.

Recommended values

Three outcomes, chosen between with two lines:

What is needed deliver-unmatched-email forward-unmatched-to
deliver as regular mail true (default) do not set
discard silently false do not set
forward to a person true a mailbox address

The combination of false plus a forwarding address does not work — the message is discarded earlier.

The true default, discarding with false and the requirement of true for forwarding to work come from the manual (§ 3.3.4.1). The analysis of what we lose is based on the Hub’s configuration.
Example configuration
# forward instead of discarding: the two lines work only together
<feedback-loop-processor>
    deliver-unmatched-email true    forward-unmatched-to postmaster@example.com
</feedback-loop-processor>
With the value no and forwarding set, the message is discarded anyway: forwarding never gets to 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 ends2 mistakes▶

Setting forwarding while leaving discarding on

§ 3.3.4.1

What it costsThe message is discarded before forwarding. The forwarding address is in the configuration, the mailbox has no messages, and there is no error either.
How to spot itThe forwarding mailbox is empty while the processor is working.
How to do it rightSet true — it is the condition for forwarding to work.

Discarding all unrecognized mail at an address people write to

our experience

What it costsOn role addresses like postmaster@ and abuse@ the processor recognizes almost nothing. With the value false you can write there as much as you like — nobody will see it.
How to spot itNobody answers messages sent to the support service at abuse@.
How to do it righttrue plus forward-unmatched-to to a live mailbox.
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-unmatched-email <boolean>
Values
yes | no | true | false
Default
true if forward-unmatched-to is not specified § 3.3.4.1
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 and its own list.
⇄

Related directives

2 relations

Same name in other blocks

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

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

How to check on the node
There is one check — send the processor’s address a message it certainly will not recognize:
grep -i "unmatched\|discard" /var/log/pmta/log | tail -20
With false the message will disappear without a trace — that is what to expect. With true it will either reach the mailbox or go to the forwarding address.
◇

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>:forward-unmatched-todeliver-matched-emailforward-errors-todeliver-emailAll 5 directives of the block →