Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 7.4.18

Which outcomes produce a report — each recipient decides

per-recipient notification
A recipient setting, not a message setting

Requesting a report is a property of the recipient, not the message. One submission can ask for different things for different addresses: watch your own, stay silent about others.

There are four values, and three of them combine: a report on success, on failure, on delay — in any combination. The fourth stands apart: report nothing.

The default matches what people usually want: report failures, stay silent otherwise.

The request travels with the recipient and is carried out at the moment of delivery: the submitting side decides, the node executes.

The main trap is requesting a success report for a bulk mailing. A success report arrives for every delivered message. For a mailing to a hundred thousand addresses that is a hundred thousand incoming messages back — while the same thing already lies in the accounting records, more precise and with no load.

The other half is quieter: the delay request. It arrives not once but on a schedule, for as long as the delay lasts — and how often is decided by the recipient setting notify-of-delay-every, not by the submitting side.

What the Hub does. It requests nothing: the sending library does not add report requests, and the protocol default — “report failures” — does not reach the node as an explicit request.

It makes no difference anyway: suppress-local-dsn true applies in the submission sources, that is, the node does not generate local reports at all. The Hub compiles outcomes from accounting records arriving via webhook — which is both more precise and cheaper than messages.

Example configuration
# the default is a report on failure only; the request is set by the submitting side
RCPT TO:<user@example.com> NOTIFY=FAILURE,DELAY
The request goes in a protocol command, not in the configuration: the node executes it but does not assign it. The value NEVER turns off reports for this recipient entirely.
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▶

Requesting a success report for a bulk mailing

§ 7.4.18

What it costsA report arrives for every delivered message. The return flow is comparable in volume to the mailing itself, even though the same information already sits in the accounting records.
How to spot itIncoming volume grows along with outgoing volume, and the content is successful-delivery reports.
How to do it rightRequest failure only, or request nothing and compile outcomes from accounting.

Expecting the sender to decide how often delay notifications come

§ 3.3.10.17

What it costsThe sender requests a notification, but how often to send it is decided by the receiver setting on the node. The expectation “they will tell us once” does not come true: as many messages arrive as fit into the interval.
How to spot itSeveral notifications arrive for a single delayed message.
How to do it rightSet the interval on the node — or do not request delay notifications at all.
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

0 relations

Referenced from

ignore-dsn<domain>With the extension turned off, the report requests the message carries from submission do not reach the receiver. § 3.3.10.80

How to check on the node
What was actually requested is visible only in the SMTP conversation itself — the node does not show it:
grep -n 'suppress-local-dsn\|notify-of-delay-every' /etc/pmta/config /etc/pmta/virtualhost.txt
grep -i 'NOTIFY=' /var/log/pmta/pmta.log | tail -10
The second command gives something only with command logging enabled. The first is more important: if local reports are suppressed, recipient requests are not executed at all, whatever they contain.
◇

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.◇A return address with the recipient written into itThe bounce arrives at a unique address, and there is no need to parse its content.◇What to return in a bounce reportWhat to enclose in a bounce report: the whole message or only its headers.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Bounce classification