Re: [ietf-smtp] DSNs

Viktor Dukhovni <> Sat, 25 April 2020 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B475C3A1334 for <>; Sat, 25 Apr 2020 11:48:01 -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 WafiYn8SUgAb for <>; Sat, 25 Apr 2020 11:47:59 -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 6CB653A1330 for <>; Sat, 25 Apr 2020 11:47:59 -0700 (PDT)
Received: by (Postfix, from userid 1001) id A19F7540AA; Sat, 25 Apr 2020 14:47:57 -0400 (EDT)
Date: Sat, 25 Apr 2020 14:47:57 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <20200409230011.F039B17637D0@ary.qy> <alpine.OSX.2.22.407.2004091945050.80689@ary.qy> <> <> <r7fq4k$1nm5$> <C1A5FAAA942E0F363CA177C0@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: Sat, 25 Apr 2020 18:48:02 -0000

On Sat, Apr 25, 2020 at 07:56:56AM -0700, Dave Crocker wrote:

> On 4/25/2020 6:01 AM, Ned Freed wrote:
> > Aside from implementation errors, I've seen no operational problems with DSNs,
> > only with the DSN extension. The problem there is that some people have
> > claimed that since NOTIFY=SUCCESS is a part of the base and they don't want to
> > do it the only alternative is to disable the entire extension. I disagree; I
> > think that since security concerns are paramount it's perfectly OK to simply
> > reject NOTIFY=SUCCESS on security grounds.
> Perhaps this goes to the challenge of a specification's distinguishing 
> its essential core, versus desired-but-not-required enhancements.
> Fail to support all of the core and it's not valid to claim to support 
> the specification.
> The danger of a pick-and-choose free-for-all is that a claim to support 
> a specification provides little useful information.

I'm very much with Dave on this one.  If you're not offering
NOTIFY=SUCCESS, then you're not offering DSN.  Pretending to support it,
but then not offering it is breakage.  On the other hand, since I ignore
"DSN" on the outbound leg, I avoid running into any problems should the
remote side misrepresent its behaviour.

There is no mechanism to offer a fine-grained subset of the DSN ESMTP
extension, so I turn it off entirely.  The only one I'd be comfortable
in offering to outsiders would be "NEVER", but the ability to avoid
some rare bounces is not that compelling.

Thus, for example, I also only send delay notices for outbound mail from
inside, but not for inbound mail from outside.