Re: [ietf-smtp] DSNs

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 26 April 2020 19:43 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 D9BF93A0FE7 for <ietf-smtp@ietfa.amsl.com>; Sun, 26 Apr 2020 12:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PdqTt0jg8rQ for <ietf-smtp@ietfa.amsl.com>; Sun, 26 Apr 2020 12:43:16 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 1B9B23A0FE3 for <ietf-smtp@ietf.org>; Sun, 26 Apr 2020 12:43:15 -0700 (PDT)
Received: by straasha.imrryr.org (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 <ietf-dane@dukhovni.org>
To: ietf-smtp@ietf.org
Message-ID: <20200426194314.GZ41308@straasha.imrryr.org>
Reply-To: ietf-smtp@ietf.org
References: <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> <01RK5UDUPC5W000058@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01RK5UDUPC5W000058@mauve.mrochek.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/i_7kOBRs3NWdqrLT0sU5oZqNCMY>
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 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:

    250-DSNNG NEVER FAILURE DELAY

with the old "DSN" retaining its original meaning:

    DSN == DSNNG NEVER SUCCESS DELAY FAILURE

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

-- 
    Viktor.