Re: [ietf-smtp] DSNs

Ned Freed <ned.freed@mrochek.com> Sun, 26 April 2020 18:57 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 85EFD3A0D91 for <ietf-smtp@ietfa.amsl.com>; Sun, 26 Apr 2020 11:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_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 bL6c-rag2TGp for <ietf-smtp@ietfa.amsl.com>; Sun, 26 Apr 2020 11:57:24 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 217593A0E21 for <ietf-smtp@ietf.org>; Sun, 26 Apr 2020 11:57:21 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RK5UE3U65C005GAR@mauve.mrochek.com> for ietf-smtp@ietf.org; Sun, 26 Apr 2020 11:52:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1587927134; bh=h4DyiAIQJJOvY+pB9g6TjD1H7lNtHTFEWXycRtjUKsA=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ZlP/Zmt4C2/yBCiKqEz3E0obOpnLdrnd1Sj88jUwKB3S3raWIqvNPsFXUg7RlUrZc Kg4vmoyyIf54kRmp3vFGYZOqVzvnfT4eHUFiXgEjP2rz+EcsJUOe/OCXYe7mT3gMby 45Odiv61E954VKiaxSXTdLJXTkSdTa3fMJQbKqvc=
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>; Sun, 26 Apr 2020 11:52:07 -0700 (PDT)
Cc: John C Klensin <john-ietf@jck.com>, Ned Freed <ned.freed@mrochek.com>, ietf-smtp@ietf.org, Viktor Dukhovni <ietf-dane@dukhovni.org>
Message-id: <01RK5UDUPC5W000058@mauve.mrochek.com>
Date: Sun, 26 Apr 2020 11:26:09 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 26 Apr 2020 08:24:07 -0700" <655b8164-7076-00b7-9f97-da8d0855b02a@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> <01RK4LP3NYJK000058@mauve.mrochek.com> <21987cb0-1cc2-e5ce-363f-5bb713333e8e@dcrocker.net> <CCD9771E28F1C5438052BB1A@PSB> <655b8164-7076-00b7-9f97-da8d0855b02a@dcrocker.net>
To: Dave Crocker <dhc@dcrocker.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/L6369loezPDc8JRNbVatKt6m27o>
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: Sun, 26 Apr 2020 18:57:27 -0000

> Also, MDN isn't an SMTP option.(*)  It's a user-level feature, unlike
> DSN.  It's independence of the transport service is why it's usable; the
> requirement for protocol support of DSN requests at every SMTP hop is
> why it has such poor -- in my experience, non-existence -- utility.

And IME almost never work. NOTIFY=SUCCESS, on the other hand...

> Success for any bit of end-to-end functionality requires:

>    Specification + Software + Deployment + Operations + Use

Depending on how you define the ends, both DSN in general and NOTIFY=SUCCESS 
in particular meet handily.

> If any one of these do not happen, the functionality fails.  If there is
> a long-term demonstration of failure, the functionality is deprecated as
> a matter of pragmatics.  Broadly any effort/expense to support it is
> therefore wasted.  (Obviously, if there are pockets of end-to-end
> support and those pockets matter to the Internet community, then it
> hasn't failed; my comments concern 'general' failure.)

All this 10,000 feet stuff is starting to make my head spin. Let's please
focus on the specific issue that's been identified here, which is that
sites are turning off the DSN extension entirely on ingress systems because
they believe they have to in order to comply with the specification.

So how do we address this issue? Well, we can:

(0) Move the entire DSN specification to historic.

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

(2) Same as (1), but only the NOTIFY=SUCCESS part.

(3) Revise the DSN specification and eliminate NOTIFY=SUCCESS.

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

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

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

(7) Do nothing.

> My comment was meant to note that, in general terms, such a long-term
> demonstration of failure for a feature warrants removing it from the
> specification. This a) makes the spec cleaner, b) clarifies to the
> community that the feature isn't supported, c) saves time/money.

Even if we believe that removal is warranted or even necessary, the devil is
always in the details. Those details are what concern me, not whether or not
making changes is justified by an overarching standards development philosophy.

				Ned