Demo
Demo

Knowledge base

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

dsn-format

<domain>

The standard report format or only its text part
in the configuration this is a linedsn-format standardinside the block <domain>
A workaround for filters that cut attachments

The default is standard: the report is sent in the standard form, as a multipart message.

With the value plain-text, only the delivery status part is returned instead of the full report, and it is returned as plain text. The manual names the purpose plainly: this way the report gets through overzealous mail filters that strip out of messages everything that looks like an attachment.

The setting is set per receiver, that is, for a specific receiving server: where the filter really cuts, not everywhere.

The second value overrides dsn-return-default: the choice of “how much of the message to return in the report” does not apply with the plain text format.

The main trap is losing parts of the report for the sake of getting through. The plain text format returns one part of the report. Everything else — the original message’s headers, the message itself if it was returned — does not reach the recipient. Machine parsing of such a report, expecting the standard form, breaks.

So the choice here is not “more convenient” but “let it arrive trimmed rather than not arrive at all”.

What the Hub does. It does not write it — and it cannot show up: suppress-local-dsn true is in effect in all submission sources, and the node does not generate report messages at all.

The Hub compiles outcomes from accounting records, and the question “in what form will a report get through someone else’s filter” does not arise for it.

Recommended values

What to set. The line is targeted, for a specific receiver:

Value When
standard (default) everywhere reports get through
plain-text a specific receiver cuts attachments, and the standard report does not reach the addressee

Setting the second in the general receivers block is not worth it: the trimmed report will go to those who accepted the full one perfectly well too.

The standard default, the composition of the returned part and the purpose “get through filters that cut attachments” come from the manual, § 3.3.10.3. The override of the volume choice — § 3.3.7.31. The advice not to set it in the general block is ours.
Example configuration
# at the receiver that cuts attachments — only there
<domain hotmail.com>
    dsn-format plain-text</domain>
The report will reach this receiver trimmed — one part instead of a multipart message. To other recipients it still goes in full.
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 the plain format in the general receivers block

§ 3.3.10.3

What it costsThe trimmed report goes to all receivers, including those who accepted the full one perfectly well. Machine parsing of reports on your side may stop working as a result.
How to spot itReports from all receivers arrive as a single text part.
How to do it rightPut the line in the block of the specific receiver that cuts attachments.

Configuring the report volume together with the plain format

§ 3.3.7.31

What it costsThe “headers or the whole message” choice is overridden with the plain text format: the format decides. The volume setting looks effective and does not work.
How to spot itReports arrive with a volume other than the one set.
How to do it rightChoose one: either the standard format with the volume setting, or plain text without 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
dsn-format <enumeration>
Values
standard | plain-text
Default
standard § 3.3.10.3
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 obeys the merging of receiver blocks: a message falls under all matching blocks, and a narrower one overrides a wider one. A value from the * block goes to all receivers that did not say otherwise themselves.
⇄

Related directives

1 relation

Conflicts with

dsn-return-default<source>The plain text format overrides the volume choice: it decides, not that line. § 3.3.7.31

How to check on the node
The setting is visible in the configuration, but it will show up only where reports are generated at all:
grep -n 'dsn-format\|suppress-local-dsn' /etc/pmta/config /etc/pmta/virtualhost.txt
If report suppression is on, this line will not show up at all. The only way to make sure the trimmed report gets through is a message to a seed mailbox at the same receiver.
◇

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
reversible: harms only while it is set
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 →