Demo
Demo

Knowledge base

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

deliver-email

<feedback-loop-processor>deprecated

The former common delivery switch — a deprecated directive
in the configuration this is a linedeliver-emailinside 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
One decision instead of two

The line decided the fate of all the processor’s messages at once. It has been declared deprecated, and the manual section consists of one sentence: use deliver-matched-email and deliver-unmatched-email.

The split did not appear for nothing. Recognized and unrecognized messages almost always need different things: the former are discarded because the data is already in accounting; the latter are delivered or forwarded because they may be anything.

The migration is not mechanical. The replacements have different defaults: deliver-matched-email — false, deliver-unmatched-email — true. So one value of the old line turns into two deliberate decisions.

The main trap is carrying the value into both lines identically. That loses the whole point of the split: either unrelated mail that deserved reading is thrown away, or recognized reports are delivered to an address without a mailbox.
What the Hub does. It does not write it: it uses both replacement lines — and sets both to no, in the bounce processor and in the feedback-loop processor. This is not a mechanical carry-over but a decision: there are no mailboxes behind the processors’ addresses, what is recognized goes to accounting, what is unrelated is discarded. The price is that unrelated mail to these addresses never reaches a human; what that threatens is analyzed under deliver-unmatched-email.

It is worth recognizing the line on sight when analyzing someone else’s configuration.

Recommended values

Carry over the decision, not the value:

What it was What it became
deliver-email no deliver-matched-email no — the data is already in accounting
deliver-unmatched-email — decide separately
deliver-email yes both yes if there is a real mailbox behind the address
The fact of deprecation and both replacement lines are from the manual (§ 3.3.4.3). The migration table and the defaults of the replacement are from § 3.3.4.1 and § 3.3.4.2.
Example configuration
# this is how it was before
<feedback-loop-processor>
    deliver-email no</feedback-loop-processor>

# this is how it is written now — two different decisions
<feedback-loop-processor>
    deliver-matched-email no
    deliver-unmatched-email true
    forward-unmatched-to postmaster@example.com
</feedback-loop-processor>
The lower block is not a carried-over value but two separate decisions: the data is already in accounting, and unrelated mail should reach a human.
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▶

Carrying one value into both lines

our experience

What it costsThe split was made precisely for different decisions. Identical values either discard unrelated messages or deliver reports to an address without a mailbox.
How to spot itBoth lines in the block have the same value.
How to do it rightDecide separately: recognized ones are usually no, unrecognized ones true with forwarding.
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-email <boolean>
Values
values not documented — the section contains only the deprecation mark
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
No inheritance: the line was written inside its own <feedback-loop-processor>. The lines replacing it live there too.
⇄

Related directives

1 relation

Replaced by

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

How to check on the node
Find the deprecated line in the configuration:
grep -rn "deliver-email" /etc/pmta/
Both processors will be found if the line is in both. Each is replaced by a pair of lines with deliberately chosen values.
◇

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
safe: a wrong value breaks nothing
Scenarios
Receiving inbound mail
Neighboring settings of the block <feedback-loop-processor>:deliver-unmatched-emailforward-unmatched-todeliver-matched-emailforward-errors-toAll 5 directives of the block →