Demo
Demo

Knowledge base

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

forward-errors-to

<feedback-loop-processor>

Where to forward messages on which parsing failed
in the configuration this is a lineforward-errors-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
Not “did not recognize” but “could not read”

The line sets an address for messages the processor could not parse. The line is repeatable: there can be several addresses.

The difference from the neighboring line is subtle and important. forward-unmatched-to is about messages that were parsed but not recognized as a complaint: ordinary mail that landed on the same address. This one is about messages on which parsing broke: a damaged structure, an unexpected encoding, a truncated body.

The second is a sign of a malfunction, not of a stray message. Regular parsing failures mean some receiver is sending reports in a format the engine does not expect — and such messages are worth looking at by eye: they may need their own pattern in <email-patterns>.

There is no default: if it is not set, no forwarding happens, and you will not learn about parsing failures.

The main trap is treating it as the same thing as forwarding unrecognized mail. Both forward, but for different reasons, and mixing them into one mailbox means drowning a rare malfunction signal in a stream of ordinary stray mail.
What the Hub does. It does not write it.

🔎 The line would be useful: a parsing failure in the feedback-loop-processor means some receiver is sending us complaints in a format the engine does not understand — which means part of the data does not reach the dashboard, and we do not know about it.

Recommended values

Route them to different mailboxes, not one:

Line What goes there How often
forward-unmatched-to stray mail to the processor’s address constantly
this one messages with broken parsing rarely, and it is a signal
The repeatability and purpose (messages the processor could not parse) come from the manual (§ 3.3.4.5). Separating the two kinds of forwarding by meaning is ours.
Example configuration
# two mailboxes: stray mail and malfunction signals — kept apart
<feedback-loop-processor>
    deliver-unmatched-email true
    forward-unmatched-to inbox@example.com
    forward-errors-to postmaster@example.com</feedback-loop-processor>
The upper mailbox gets a constant flow, the lower one rarely, and every message in it is worth reading.
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▶

Sending both kinds of forwarding to one mailbox

our experience

What it costsStray mail comes constantly, parsing failures rarely. In a shared mailbox the rare malfunction signal drowns in the flow of ordinary mail.
How to spot itThe forwarding mailbox is full, and nobody takes on going through it.
How to do it rightSplit them into two addresses: one is read selectively, the other always.
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-errors-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 concerns only its parsing. The neighboring processor has its own such line.
⇄

Related directives

2 relations

Same name in other blocks

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

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

How to check on the node
Parsing failures are visible in the engine’s log:
grep -i "parse\|malformed" /var/log/pmta/log | tail -20
Regular entries mean some receiver is sending reports in an unexpected format. Such a message is worth looking at by eye and, if the format is stable, describing with a pattern in <email-patterns>.
◇

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