Re: [ietf-smtp] DSNs

Ned Freed <ned.freed@mrochek.com> Sat, 25 April 2020 21:38 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E8C3A0A2E for <ietf-smtp@ietfa.amsl.com>; Sat, 25 Apr 2020 14:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-IZtlrK1omY for <ietf-smtp@ietfa.amsl.com>; Sat, 25 Apr 2020 14:38:11 -0700 (PDT)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6CE3A0A29 for <ietf-smtp@ietf.org>; Sat, 25 Apr 2020 14:38:11 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RK4LP66DJK0053TR@mauve.mrochek.com> for ietf-smtp@ietf.org; Sat, 25 Apr 2020 14:33:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1587850383; bh=9EWAP5Z01aXvdXD5xlE3ChMsVX59PdlD+ZVZKWDjYlE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Bi8qUnMwO0P7nIbVtTUnMU4nSbZFpdDPl/j3Uk0odoxfxV5w9iP7obMA00KffuBZL Pc2vjJDPubMPFzhHa+/DzQQJR0l9xxh+QOaMbHm5lMSS5tuto2Bmabn9e+FVumR6V6 kURZKRcaXIqPxnKRsriHES+rwatJ6BgbsO0dQe3U=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJM3XSTRLC000058@mauve.mrochek.com>; Sat, 25 Apr 2020 14:33:00 -0700 (PDT)
Cc: Ned Freed <ned.freed@mrochek.com>, Viktor Dukhovni <ietf-dane@dukhovni.org>, ietf-smtp@ietf.org
Message-id: <01RK4LP3NYJK000058@mauve.mrochek.com>
Date: Sat, 25 Apr 2020 14:15:23 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sat, 25 Apr 2020 07:56:56 -0700" <22e05a3b-bf47-9d83-a340-720ca9a373c4@dcrocker.net>
References: <20200409230011.F039B17637D0@ary.qy> <alpine.OSX.2.22.407.2004091945050.80689@ary.qy> <20200410090430.GA75736@kiel.esmtp.org> <29104A0F-B9ED-4CD7-99B3-5A042375C68B@dukhovni.org> <r7fq4k$1nm5$1@gal.iecc.com> <C1A5FAAA942E0F363CA177C0@PSB> <20200425013624.GV41308@straasha.imrryr.org> <01RK47G4QUK0000058@mauve.mrochek.com> <22e05a3b-bf47-9d83-a340-720ca9a373c4@dcrocker.net>
To: Dave Crocker <dhc@dcrocker.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/q4En18TSnZb7XJ4_Hram-dtMjhw>
Subject: Re: [ietf-smtp] DSNs
X-BeenThere: ietf-smtp@ietf.org
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\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Apr 2020 21:38:13 -0000

> 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.

Completely inapplicable in this case, I'm afraid. One of the primary goals of
the NOTARY effort, if not the primary goal, was feature parity with X.400.
And the operational model for X.400 was success receipts as the default.

So the feature had to be part of the core. 

But thinkgs change. X.400 collapsed - a casualty of even more serious
design errors than success DSNs. Spam became email's biggest problem,
which made NOTIFY=SUCCESS less desirable. Privacy concerns also arose that
weren't even on the radar at the time this work was done.

> Fail to support all of the core and it's not valid to claim to support
> the specification.

It's not a question of support, it's a question of operational policy. Every
implementation of the DSN extension I've seen has no problem supporting
NOTIFY=SUCCESS. THe debate has been over whether or not it's legitimate to have
an operational policy of bouncing messages that ask for it.

Of course there's also the issue of whether or not the extension, eith
or without NOTIFY=SUCESS, is of sufficient value to enable. Some people
see little value here, and the NOTIFY=SUCCESS situation is sufficiently
bothersome to tip the scale to dropping the extension.

> The danger of a pick-and-choose free-for-all is that a claim to support
> a specification provides little useful information.

Dave, we're talking about having an operational policy of restricing the use of
exactly one feature which made sense when the standard was defined but has
issues today. This is hardly a pick-and-choose free-for-all.

				Ned