Re: [ietf-smtp] SMTP, DSNs, and enhanced replies

Ned Freed <ned.freed@mrochek.com> Fri, 10 April 2020 02:37 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 C1A323A19A3 for <ietf-smtp@ietfa.amsl.com>; Thu, 9 Apr 2020 19:37:49 -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 uU5-evf_LvJe for <ietf-smtp@ietfa.amsl.com>; Thu, 9 Apr 2020 19:37:48 -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 A0E773A1998 for <ietf-smtp@ietf.org>; Thu, 9 Apr 2020 19:37:45 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJIJMHS82O005FVM@mauve.mrochek.com> for ietf-smtp@ietf.org; Thu, 9 Apr 2020 19:36:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1586486172; bh=9vTF8etJngFvE383ZPizQdLQXa2sqlJ6rx9cVLvRiIs=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Yq/uxIOwokRROiDEfKTQWz429CNldKW/tcDpxpLsIAczUACQ0e6qUhFRU3y13ARAY AZWxktlK30oR8awY1kh1w5QWZVSRKABZZPdQiP4sX9qgVZN8zpDdXZlR8YYGWA3oWd XWoRHgTdYeDNH4SBO2rUYsLfmH5ynufAGCSv2kSM=
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 <01RIHLDFQH34000058@mauve.mrochek.com>; Thu, 9 Apr 2020 19:36:09 -0700 (PDT)
Cc: John Levine <johnl@taugh.com>, ietf-smtp@ietf.org, blong@google.com
Message-id: <01RJIJMGBSMI000058@mauve.mrochek.com>
Date: Thu, 09 Apr 2020 19:26:36 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 09 Apr 2020 16:11:33 -0700" <693d848e-3a83-c1c8-f806-a129a0ab2713@dcrocker.net>
References: <20200409230011.F039B17637D0@ary.qy> <693d848e-3a83-c1c8-f806-a129a0ab2713@dcrocker.net>
To: Dave Crocker <dhc@dcrocker.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/mQH4PXP7ip-qCZivts7um60Nkmg>
Subject: Re: [ietf-smtp] SMTP, DSNs, and enhanced replies
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: Fri, 10 Apr 2020 02:37:50 -0000

> On 4/9/2020 4:00 PM, John Levine wrote:
> > My impression is that these days if you get a bounce it's usually a DSN.


> Right.  I thinking of the SMTP mechanism for a client's /requesting/ its
> use, which as far as I has not gained widespread use.

Widely supported, not widely enabled. THe main issue IME is success DSNs. The
way the standard reads you have to support them or be noncompliant. i tell
people security needs override that and to simply reject messages that request
them for security reasons.

Including the SUCCESS machenism was a mistake, but we were quite concerned
about feature parity with X,400 at the time - yes, this is that old - and
blowback wasn't on the radar.

But perhaps the real reason is that none of the mechanism the extension
provides have proven to be essential. Most applications for envelope ids and
original recipient addresses have been implement with more reliable VERP schems
instead, the ability to turn off DSNs completely has always been present, and
control over return of content is (a) Less useful because message sizes aren't
as relevant, (b) Something you don't want th sender to have control over
because of phishing/viral content, and (c) Something you don't want people to
be able to do for really large messages.

				Ned