Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.29

dsn-failed-from-template

Global

The From header template in failure reports
in the configuration this is a linedsn-failed-from-templateinside the block Global
Who the report comes from

The value is the From header line for the generated report. The substitutions are the same nine as in the other templates; their list is at dsn-failed-body-template-from.

There are two lines with this purpose. The older custom-dsn-from-header sets the header verbatim, without substitutions; this one — with them. That is the whole difference, and there is no point keeping both in the configuration.

The manual names no default — if it is not written, the engine uses its own.

The main trap is an address nobody looks at. The report comes to the sender of the original message, and they will reply to it: ask why the message did not arrive, complain, ask to be unsubscribed. The address in this header must lead to a mailbox that is read, not to postmaster@ on the node, from which nobody collects mail.

The second half is the usual one for this group: the manual writes the substitution name in two ways, and a wrong spelling will stay in the header as is.

What the Hub does. It does not write it — and the line cannot show up: report generation is turned off by suppress-local-dsn in all submission sources.

The same question — “where will a person who saw our service message write to” — the Hub solves elsewhere: receiving to role addresses is opened by the /^(dmarc|postmaster|abuse)@/ rule, and mail there is handled by the processor.

Recommended values

What to set. There is one requirement, and it is not about the format:

Value When
do not write it reports are not generated or are parsed by a machine
the address of a mailbox that is read reports go to people, and they will reply to them

Substituting the node name into the display name is handy in investigations: it shows at once which node generated the report.

The purpose, support for substitutions and the shared set with the body template come from the manual, § 3.3.1.29. No default is named there. The requirement for the address is ours.
Example configuration
# the node name in the display name helps in investigations
dsn-failed-from-template "${hostname} <postmaster@abc.com>"
The substitution gives the name of the node that generated the report. The address must lead to a mailbox that is read: people reply to reports.
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 an address nobody collects mail from

our experience

What it costsPeople reply to reports: they ask why the message did not arrive, complain, ask to be unsubscribed. The replies go to a mailbox nobody reads, and the person thinks you are not answering.
How to spot itThe header has the node’s service address, not a working mailbox.
How to do it rightSpecify a mailbox that is read, and make sure receiving to it is opened by a rule.

Keeping both sender header lines

§ 3.3.1.28

What it costsThe old one sets the header verbatim, the new one with substitutions. Which one wins, the manual does not specify, and it will have to be figured out by experiment.
How to spot itBoth lines appear in the configuration.
How to do it rightKeep the one you need: with substitutions — this one, verbatim — the neighboring one.
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
dsn-failed-from-template "<template>"
Values
a From header line with substitutions
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive is written at the root of the configuration file and applies to the whole node: there is no block for it and no inheritance either. Different report senders for different domains cannot be set.
⇄

Related directives

1 relation

Depends on

dsn-failed-body-template-fromGlobalThe set of substitutions common to all three report templates is listed there. § 3.3.1.29

Referenced from

custom-dsn-from-headerGlobalThe same task with substitutions; this one sets the header verbatim. § 3.3.1.29

How to check on the node
Check both the line and what stands next to it:
grep -n 'dsn-failed-from-template\|custom-dsn-from-header\|suppress-local-dsn' /etc/pmta/config
If both sender header lines are found, the configuration needs to be brought down to one. If report suppression is on, neither of them will show up.
◇

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 Global:dsn-failed-subject-templatecustom-dsn-from-headerdsn-failed-body-template-frompostmasterhost-nameAll 108 directives of the block →