Demo
Demo

Knowledge base

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

ignore-dsn

<domain>

Do not use the DSN extension even if the receiver announced it
in the configuration this is a lineignore-dsn falseinside the block <domain>
Do not ask the receiver for a report on the message’s fate

The DSN extension lets the sender ask the receiver to send a report on the message’s fate — delivered, delayed, bounced. The request is passed as parameters of the MAIL FROM and RCPT TO commands and arrives together with the message submission. The line cancels passing it on.

The receiver announces the extension in its reply to EHLO, among the lines with code 250. As long as the node sees this announcement and the line is off, the requests go out.

The difference from the other lines of the family is that data is lost here, not a mechanism. By turning off pipelining, you slow down the conversation; by turning off DSN, you stop receiving reports that someone at submission ordered.

The main trap is that someone else’s logic breaks silently. The application submitting messages may have asked for a delay or delivery report and be waiting for it. With the line on, the request does not go out, the report does not arrive, and the application considers the message lost — even though it was delivered.
What the Hub does. It does not write it — the vendor false stays. The Hub does not use delivery reports from receivers: it counts delivery by its node’s accounting records, not by other parties’ reports. But the submitting application may use them, and turning the extension off on its behalf is not a good idea.
Recommended values

Leave it off if you do not know who requests reports. The request comes with submission; the node only passes it on.

Enable it for a receiver that responds with garbage. There are servers that announce the extension and send unparseable reports in response; there turning it off is appropriate.

Do not confuse it with bounces. A bounce always arrives regardless of this line: it is part of the ordinary conversation, not an extension.

The split “report versus bounce” and the sign for enabling are ours. From the manual come the default and the fact that the receiver announces the extension among the replies with code 250.
Example configuration
# the receiver announces DSN and sends unparseable reports
<domain broken-dsn.example.com>
    ignore-dsn true</domain>
Bounces from this receiver will not stop arriving: they are part of the ordinary conversation and have nothing to do with the extension.
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▶

Enabling it “to avoid getting unnecessary messages”

our experience

What it costsDelivery reports are not a mailing and not complaints: someone ordered them at submission. Turning it off breaks the submitting application’s logic, and a message that was delivered is considered lost.
How to spot itThe submitting application reports undelivered messages that are not among the bounces.
How to do it rightFind out who orders the reports, and turn the extension off only for a specific receiver.

Expecting bounces to stop arriving

our experience

What it costsA bounce arrives in the ordinary conversation and does not depend on the extension. The line has no effect on it whatsoever.
How to spot itThe line is on, bounces keep arriving.
How to do it rightBounces are controlled by other lines — the bounce-after term and the conditions for early bouncing.
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
ignore-dsn <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.80
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 value is merged across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It is picked up by pmta reload; it does not affect open connections.
⇄

Related directives

1 relation

Affects

Which outcomes produce a report — each recipient decidesWith the extension turned off, the report requests the message carries from submission do not reach the receiver. § 3.3.10.80

How to check on the node
The value is printed by the queue settings command; whether the receiver announces the extension is visible in its reply to EHLO:
pmta show settings broken-dsn.example.com/vmta1 | grep -i ignore-dsn
grep -i '250-DSN' /var/log/pmta/pmta.log | tail -10
If there is no line with the extension in the log, the receiver does not announce it and there is nothing to turn off. The Hub does not use delivery reports.
◇

What else to read

3 articles

◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Reputation monitoring inside the nodeThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Tune the pace for a provider
Neighboring settings of the block <domain>:connect-timeoutauth-usernamecommandallow-cancel-during-transferassume-delivery-upon-data-termination-timeoutAll 135 directives of the block →