Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 13.1

What to do with an accepted message

inbound dispositions
Six outcomes for an accepted message

Inbound mail not submitted by its own platform — bounces that arrived by mail, complaints, service mail — the node can accept and do one of six things with: forward it to another server, write it to a file, discard it, pass it to a local program, parse it as a bounce or parse it as a complaint. The ways can be combined.

Accepting and delivering are different things. Each outcome leaves its own delivery accounting record, and a discarded message looks different in accounting than a rejection at reception.

The main trap is allowing reception without a rule for what comes next. The permission to accept (relay-address) and the message’s fate are different lines: without a processor or a delivery rule, accepted mail goes into an ordinary queue and starts looking for a mailbox that does not exist.
What the Hub does. It accepts three kinds of inbound mail on port 25 and forwards none of it: bounces at bounce@bounce.<domain> and the role addresses dmarc@, postmaster@, abuse@ — with the bounce processor, complaints at fbl@fbl.<domain> — with the complaint processor. What is recognized turns into accounting records, the rest is discarded.
Recommended values

Outcomes and their settings:

Outcome What sets it
forward a domain route to another server
write to a file the file delivery method
discard the discard delivery method
pass to a program the pipe delivery method
parse a bounce <bounce-processor>
parse a complaint <feedback-loop-processor>
The six outcomes and the accounting record for each come from the manual (§ 13.1–13.7). The mapping to settings is ours.
Example configuration
# accept service mail for your own domains and discard it without forwarding
relay-address /^(dmarc|postmaster|abuse)@/
<bounce-processor>
    deliver-unmatched-email no
    <address-list>
        address /^(dmarc|postmaster|abuse)@/    </address-list>
</bounce-processor>
This is what the Hub node does: the permission to accept and the rule for the message’s fate are written as separate lines.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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.
⇄

Related entries

3 relations

Can be replaced by

Hand a message to a webhook instead of a receiverA related mechanism: they work together. inference

Applies to

How a message leaves the nodeA related mechanism: they work together. § 13.1

Where you can see it

ReceivedThe accounting record in which the result is visible. § 13.1

How to check on the node
Check what inbound mail turns into:
grep -hE '^(rb|f),' /var/log/pmta/acct*.csv | tail -5
Inbound mail stuck in the ordinary queues of your domains is a sign that the rule for its fate did not work.
◇

What else to read

3 articles

◇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.◇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.◇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
Bounce classification · Receiving inbound mail