Re: [ietf-smtp] DSNs

Viktor Dukhovni <> Sun, 26 April 2020 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9BF93A0FE7 for <>; Sun, 26 Apr 2020 12:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1PdqTt0jg8rQ for <>; Sun, 26 Apr 2020 12:43:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B9B23A0FE3 for <>; Sun, 26 Apr 2020 12:43:15 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 584E154F08; Sun, 26 Apr 2020 15:43:14 -0400 (EDT)
Date: Sun, 26 Apr 2020 15:43:14 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <r7fq4k$1nm5$> <C1A5FAAA942E0F363CA177C0@PSB> <> <> <> <> <> <CCD9771E28F1C5438052BB1A@PSB> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <>
Subject: Re: [ietf-smtp] DSNs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Apr 2020 19:43:26 -0000

On Sun, Apr 26, 2020 at 11:26:09AM -0700, Ned Freed wrote:

> So how do we address this issue? Well, we can:
> (0) Move the entire DSN specification to historic.

I don't believe that's warranted.

> (1) Revise DSN saying it should only be used within an ADMD.

Though I usually give that advice informally, SHOULD would IMHO be too
strong, I think this is closer to MAY, i.e. something along the lines of
(non-normative lower case):

    operators should consider whether limiting the use of DSN to just
    inside their ADMD is appropriate for them.

> (2) Same as (1), but only the NOTIFY=SUCCESS part.
> (3) Revise the DSN specification and eliminate NOTIFY=SUCCESS.

There is no interoperable way to do that without introducing a new ESMTP
extension keyword, along the lines of:


with the old "DSN" retaining its original meaning:


> (4) Change the specification to make it clear you can reject NOTIFY=SUCCESS,
>     and specify a status code for that purpose. (This could be done in a
>     follow-on document.)

No, that's broken.  Existing MTAs won't know about the shiny new DSN
semantics and will bounce the message, 

> (5) In addition to (4), deprecate NOTIFY=SUCCESS.

Though "DSNNG" could be defined without SUCCESS, while the utility of
SUCCESS is limited, and we should recommend that it not be turned on
"DSNNG" by default, I think that SUCCESS should be retained, for cases
(say within an ADMD) where it can be useful.

> (6) In addition to (4), add some sort of indicator to EHLO that NOTIFY=SUCCESS
>     will be rejected.

This too is broken, but would be addressed with a "DSNNG".

> (7) Do nothing.

This is also an option, with the only downside being that when chooses
to neither offer nor consume DSN SUCCESS across ADMD boundarie, one also
loses the other options.