Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.28

custom-dsn-from-header

Global

The From header in generated reports, set verbatim
in the configuration this is a linecustom-dsn-from-headerinside the block Global
The verbatim form of the same header

The value is the From header line for reports the node generates. It does not support substitutions: the text goes into the header verbatim.

There are two lines with this purpose, and they differ in exactly this. The neighboring dsn-failed-from-template can substitute nine values of the original message — the node name, the sender, the recipient, the subject and the rest. This one can do nothing of the kind.

There is no point keeping both in the configuration: which one wins, the manual does not specify.

No default is named either — if it is not written, the engine uses its own.

The main trap is an address nobody collects mail from. The report goes to the sender of the original message, and they will reply to it. The classic Postmaster <postmaster@…> from the manual’s example is suitable only where that mailbox is really read, and receiving to it is opened by a rule.

The second half: the line is silent about substitutions. By writing ${hostname} in it, you will get exactly those characters in the header — with no error and no warning.

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.
Recommended values

What to set. A choice between two lines with the same purpose:

Value When
do not write it reports are not generated, or the engine’s default is enough
a verbatim string you need the same report sender every time, and no substitutions

If you want the node name in the display name, you need the neighboring line with substitutions, not this one.

The purpose and the example come from the manual, § 3.3.1.28. No default is named there, and support for substitutions is not mentioned — unlike the neighboring line, where it is named directly. The conclusion that there are no substitutions is ours.
Example configuration
# verbatim: substitutions do not work here
custom-dsn-from-header "Postmaster <foobar@there.com>"
The text goes into the header as is. If you need the node name or the subject substituted, this line will not do — you need the neighboring one, with a template.
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▶

Writing a substitution in the verbatim line

§ 3.3.1.29

What it costsThe substitution characters go into the header as is. There will be no error, and the recipient will see curly braces instead of the node name.
How to spot itThe substitution name is visible in the header of the received report.
How to do it rightMove the line to the template form — substitutions work only there.

Setting an address nobody collects mail from

our experience

What it costsPeople reply to reports, and the replies go to an unread mailbox. The person thinks you are not answering and, as the next step, complains to the receiver.
How to spot itThe header has the node’s service address, and receiving to it is not opened by a rule.
How to do it rightSpecify a mailbox that is read, and open receiving to it.
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
custom-dsn-from-header "<display name and address>"
Values
a From header line, without 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

Can be replaced by

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

How to check on the node
Both sender header lines need to be checked at once:
grep -n 'custom-dsn-from-header\|dsn-failed-from-template\|suppress-local-dsn' /etc/pmta/config
If both are found, the configuration needs to be brought down to one: the manual does not say which one wins. If report suppression is on, neither 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-templatedsn-failed-body-template-fromdsn-failed-from-templatepostmasterhost-nameAll 108 directives of the block →