Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.9

deliver-local-dsn

<domain>deprecated

Whether to generate reports for mail accepted from this domain
in the configuration this is a linedeliver-local-dsn trueinside the block <domain>
The deprecated half of the same task

The default is true. The line decided whether to generate outcome reports — bounce, delay, delivery — for messages accepted from the domain named in this block.

Accounting records were written as usual meanwhile: only the report messages were suppressed.

The directive has been declared deprecated. The replacement is suppress-local-dsn in the source block, and the difference between them is not only in the name: the old one selected by the message’s sender domain, the new one by the submission source. The latter is more precise: the node knows the source reliably, while the sender domain is set by the submitting side.

The main trap is keeping both lines at once. They solve one task from different sides, and the combination “suppressed by source, allowed by domain” reads ambiguously. Which one wins can only be found out by experiment — and there is no need: the new line covers all the cases of the old one.
What the Hub does. It does not write it: it uses the replacement — suppress-local-dsn true is in effect in all submission sources.

The deprecated line is worth looking for in configurations assembled by hand before the move to the Hub: it does occur there and silently conflicts with the new one.

Recommended values

What to set. Nothing: the line should be removed.

Value When
do not write always: the task is solved by the source block setting
no only in an old configuration that has not been migrated yet

The migration is simple: suppression moves into the source block that the submission falls under, and stops depending on what the submitting side wrote in the return address.

The default true, the caveat “accounting records are written as usual” and the deprecation mark naming the replacement are from the manual, § 3.3.10.9. The analysis of the difference “sender domain versus submission source” is ours.
Example configuration
# this is how it was before — by the return address domain
<domain bounce.port25.com>
    deliver-local-dsn no</domain>
Today the same thing is written in the source block with the suppression line: it selects by the submitting side, not by the domain that side named as the return address.
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▶

Leaving the deprecated line next to the new one

§ 3.3.10.9

What it costsTwo lines solve one task from different sides, and the combination reads ambiguously. Which one won will have to be found out by experiment.
How to spot itBoth occur in the configuration.
How to do it rightRemove the deprecated one: the new one covers all its cases.

Relying on selection by sender domain

our experience

What it costsThe return address domain is set by the submitting side, and it can be anything. Suppression tied to it is bypassed by changing the return address — accidentally or deliberately.
How to spot itReports arrive for part of the submission even though suppression is configured.
How to do it rightMove suppression into the source block: the node knows the source reliably.
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-local-dsn <boolean>
Values
yes | no | true | false
Default
true § 3.3.10.9
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and follows the merging of recipient blocks — but it selects not the recipient but the sender domain of the accepted message. This oddity is exactly what led to the replacement: the new line lives where the selection is natural — in the source block.
⇄

Related directives

1 relation

Replaced by

suppress-local-dsn<source>The replacement: the same task, but selecting by submission source rather than by sender domain. § 3.3.10.9

How to check on the node
The deprecated line is worth looking for together with its replacement:
grep -n 'deliver-local-dsn\|suppress-local-dsn' /etc/pmta/config /etc/pmta/virtualhost.txt
If both are found, the configuration should be brought to one: remove the deprecated line, set suppression in the source block.
◇

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 <domain>:smtp-553-means-invalid-mailboxsmtp-pattern-listbounce-category-patternsbounce-upon-no-mxbounce-upon-5xx-greetingAll 135 directives of the block →