Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.30

suppress-local-dsn

<source>set by the Hub

Whether to generate outcome reports for mail from this source
in the configuration this is a linesuppress-local-dsn falseinside the block <source>
A report by email or a record in accounting

The line decides whether the node will generate report messages about the delivery outcome for mail accepted from this source — about a bounce, a delay, a success.

Accounting records are written as usual. This is the key point: what is suppressed is not the information about the outcome but the way it is delivered. The data does not go anywhere — it sits in the accounting file and goes out via the webhook, if one is configured.

The line replaced the older deliver-local-dsn, which did the same thing from the sender’s side rather than the source’s, and has been declared obsolete.

The main trap is suppressing reports without having a replacement. Report messages are inconvenient, but they are the only channel that works without setup. Having turned them off without setting up accounting parsing, you will be left with no information about outcomes at all — and you will not find out right away, because silence looks like “everything is being delivered.”

The other half: suppression applies to messages accepted from the source, not messages sent to it. It is easy to read the line the other way around, and then it ends up in the wrong block.

What the Hub does. It writes true in the general 0/0 source — both in the base configuration and in the working one; the address-based submission sources get the value from there by merging. Separately the line is set in each named login-based submission source: the general source’s directives do not carry over to an authenticated connection.

It has a replacement, and a real one: outcomes arrive as accounting records via the telemetry webhook — deliveries, bounces, transient failures and complaints. Report messages in this scheme would be a second channel for the same data, only slower and with a load on the queues.

It follows that all the settings for the appearance and content of reports — subject, body, header templates — have no effect for us at all.

Recommended values

What to set. The answer depends on whether you have accounting parsing:

Value When
false (default) information about outcomes comes from report messages — the only channel that needs no setup
true accounting is parsed by a machine: from a file, a webhook or both

The second is the usual choice for a sending platform. But it is worth enabling after accounting parsing has started working, not before: the reverse order leaves you without information for the whole setup period.

The purpose and the caveat “accounting records are written as usual” come from the manual, § 3.3.7.30. The replacement of the obsolete directive is from § 3.3.10.9. The advice about the enabling order is ours.
Example configuration
# this is how the Hub writes the configuration — outcomes arrive as accounting, not as messages
<source 0/0>
    suppress-local-dsn true</source>
Accounting records keep being written: only report messages are suppressed. All the settings of their appearance — subject, body, header templates — then stop having any effect.
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 ends3 mistakes▶

Suppressing reports before accounting parsing is set up

our experience

What it costsInformation about outcomes is lost for the whole setup period, and silence looks like successful delivery. This is discovered through complaints or mismatched numbers, not right away.
How to spot itNo bounces are visible either in mail or in the platform’s reports.
How to do it rightEnable suppression after accounting records are being parsed and reaching your side.

Putting the line into the wrong source's block

§ 3.3.7.30

What it costsSuppression applies to mail accepted from this source. Read the other way around, it ends up in a block through which mail is not submitted, and has no effect.
How to spot itReports keep coming even though the line is in the configuration.
How to do it rightPut the line in the block the submitting side falls under.

Using the obsolete directive instead of this one

§ 3.3.10.9

What it costsThe former line has been declared obsolete and lives in the recipient block, not the source block: it suppressed reports by the sender’s domain. Mixing them in one configuration is a sure way to get an unexpected result.
How to spot itBoth lines appear in the configuration.
How to do it rightKeep only this one and remove the obsolete 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
suppress-local-dsn <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.30
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source> and follows source merging: a connection falls under all address blocks that cover it, and a narrow one overrides a broad one. For submission under a login the named block applies — the Hub repeats the line there too, because we did not see inheritance from address blocks into a named one.
⇄

Related directives

1 relation

Affects

dsn-failed-body-template-fromGlobalSuppression cancels all report appearance settings at once: there will simply be no message to format. § 3.3.7.30

Referenced from

dsn-return-default<source>Decides whether to send a report at all; this one — how much of the message to put in it. § 3.3.7.31deliver-local-dsn<domain>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 setting is visible in the configuration; making sure the replacement works matters more than the line itself:
grep -n 'suppress-local-dsn\|deliver-local-dsn' /etc/pmta/config /etc/pmta/virtualhost.txt
grep -n -A4 '^<acct-file' /etc/pmta/config
The second command shows where accounting records go. If suppression is on but the accounting block is not configured, information about outcomes is not stored anywhere.
◇

What else to read

3 articles

◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇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.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.

In the Hub
Managed at
Analytics → Node accounting
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform
Neighboring settings of the block <source>:verp-defaultdsn-return-defaultretain-x-dkim-keyprocess-x-dkim-keysmtp-serviceAll 74 directives of the block →