Re: [ietf-smtp] DSNs
John C Klensin <john-ietf@jck.com> Sat, 18 April 2020 23:10 UTC
Return-Path: <john-ietf@jck.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 9C68B3A13D2 for <ietf-smtp@ietfa.amsl.com>; Sat, 18 Apr 2020 16:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 T4TqkF8XtXtV for <ietf-smtp@ietfa.amsl.com>; Sat, 18 Apr 2020 16:10:29 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F193A13D4 for <ietf-smtp@ietf.org>; Sat, 18 Apr 2020 16:10:29 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jPwbU-000Bkj-7k; Sat, 18 Apr 2020 19:10:28 -0400
Date: Sat, 18 Apr 2020 19:10:21 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>, ietf-smtp@ietf.org
Message-ID: <C1A5FAAA942E0F363CA177C0@PSB>
In-Reply-To: <r7fq4k$1nm5$1@gal.iecc.com>
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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/16pFmP8qU-22U1enXRYWpGdS2z0>
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, 18 Apr 2020 23:10:34 -0000
--On Saturday, April 18, 2020 21:06 +0000 John Levine <johnl@taugh.com> wrote: > In article <29104A0F-B9ED-4CD7-99B3-5A042375C68B@dukhovni.org>, > Viktor Dukhovni <ietf-smtp@ietf.org> wrote: >>> On Apr 10, 2020, at 5:04 AM, Claus Assmann >>> <ietf-smtp@esmtp.org> wrote: >>> >>> On Thu, Apr 09, 2020, John R Levine wrote: >>> >>>> Oh, RFC 3461. Agreed, it's basically an SMTP level web >>>> bug. Nobody implements that. >>> >>> sendmail implemented it too (more than 20 years ago?). I >>> guess it should read "nobody enables/uses it"? >> >> And likewise Postfix also implements RFC3461. It is on by >> default. I turn it off on inbound edge systems, and ignore >> remote "DSN" on outbound edge systems. That way, any DSNs >> are sent within either my or the remote ADMD, but not across >> ADMD boundaries. ... > > I meant that nobody sends positive DSNs. You're right, we get > lots of DSN bounces. But, fwiw, I occasionally (very rarely) request delivery and/or read receipts and sometimes (especially for the former) get responses and get them in DNS form. It may not be common, but terms like "nobody" are a little strong. And that brings me back to what I think are the key questions as far as some potential WG that looks at 5321/5322 updates and maybe their relationship to other email specs: (1) Are DSNs implemented broadly enough that it is reasonable to claim that the spec is good enough to allow interoperability? Because RFC 3461 met the interoperability criteria for Draft Standard 17 years ago, I think the only basis for claiming the answer to that question is not "yes" would be the discovery of some horrible problem in the specification that, if known, would have produced a "no" answer when 3461 was reviewed and approved. (2) Have they been deployed sufficiently to demonstrate that they are perceived of as useful by at least some of the people some of the time. Noting that the requirements for full standard do not distinguish between good and evil users, the number of DNS requests --especially for read acknowledgments-- I see in a month seems to make the case even if I don't choose to have those acknowledgements sent back out. (3) Have the specification or the feature proven sufficiently problematic that we should be moving to deprecate RFC 3461 and/or the specifications that depend on it and/or update it? I haven't heard that argument yet. And that leads to a question that I think is quite separate from the above: (4) Are DNSs sufficiently problematic under various conditions that have been observed in the current world that we would recommend that at least some of them not be used -- and requests for them either rejected or ignored -- unless they are accompanied by some mechanism that allows verification of the legitimacy of the requestor and request and/or that the reply is actually a response to a request and requestor. Unless the answers to some of those questions require changes to the DSN spec(s) themselves, it seems to me they are matters for an applicability statement about when and how DSNs should be used (or not used) and not about the DNS specs. Anyway, that is my analysis after reflecting on the recent thread. YMMD, of course. best, john
- [ietf-smtp] SMTP, DSNs, and enhanced replies (was… John C Klensin
- Re: [ietf-smtp] SMTP, DSNs, and enhanced replies … Hector Santos
- Re: [ietf-smtp] SMTP, DSNs, and enhanced replies … Dave Crocker
- Re: [ietf-smtp] SMTP, DSNs, and enhanced replies … Brandon Long
- Re: [ietf-smtp] SMTP, DSNs, and enhanced replies … John Levine
- Re: [ietf-smtp] SMTP, DSNs, and enhanced replies Dave Crocker
- Re: [ietf-smtp] SMTP, DSNs, and enhanced replies John R Levine
- Re: [ietf-smtp] SMTP, DSNs, and enhanced replies … Ned Freed
- Re: [ietf-smtp] SMTP, DSNs, and enhanced replies Ned Freed
- Re: [ietf-smtp] SMTP, DSNs, and enhanced replies Jeremy Harris
- Re: [ietf-smtp] DSNs Claus Assmann
- Re: [ietf-smtp] DSNs Viktor Dukhovni
- Re: [ietf-smtp] DSNs John Levine
- Re: [ietf-smtp] DSNs John C Klensin
- Re: [ietf-smtp] DSNs John Levine
- Re: [ietf-smtp] DSNs Alessandro Vesely
- Re: [ietf-smtp] DSNs Viktor Dukhovni
- Re: [ietf-smtp] DSNs Ned Freed
- Re: [ietf-smtp] DSNs Dave Crocker
- Re: [ietf-smtp] DSNs Viktor Dukhovni
- Re: [ietf-smtp] DSNs Dave Crocker
- Re: [ietf-smtp] DSNs Ned Freed
- Re: [ietf-smtp] DSNs Dave Crocker
- Re: [ietf-smtp] DSNs Jeremy Harris
- Re: [ietf-smtp] DSNs John C Klensin
- Re: [ietf-smtp] DSNs Scott Kitterman
- Re: [ietf-smtp] DSNs John C Klensin
- [ietf-smtp] Variable HELO name, was DSNs Alessandro Vesely
- Re: [ietf-smtp] DSNs Arnt Gulbrandsen
- Re: [ietf-smtp] Variable HELO name, was DSNs Ned Freed
- Re: [ietf-smtp] Variable HELO name, was DSNs John C Klensin
- Re: [ietf-smtp] DSNs John C Klensin
- Re: [ietf-smtp] DSNs Dave Crocker
- Re: [ietf-smtp] DSNs Ned Freed
- Re: [ietf-smtp] DSNs Viktor Dukhovni
- Re: [ietf-smtp] DSNs John Levine
- Re: [ietf-smtp] DSNs Sam Varshavchik
- Re: [ietf-smtp] DSNs Valdis Kl ē tnieks
- Re: [ietf-smtp] DSNs Scott Kitterman
- Re: [ietf-smtp] DSNs John Levine
- Re: [ietf-smtp] DSNs Sam Varshavchik
- Re: [ietf-smtp] DSNs Valdis Kl ē tnieks
- Re: [ietf-smtp] DSNs Laura Atkins
- Re: [ietf-smtp] DSNs Sam Varshavchik
- Re: [ietf-smtp] DSNs John Levine
- Re: [ietf-smtp] DSNs Sam Varshavchik
- Re: [ietf-smtp] DSNs John Levine
- Re: [ietf-smtp] DSNs Sam Varshavchik
- Re: [ietf-smtp] DSNs Ned Freed
- Re: [ietf-smtp] DSNs Viktor Dukhovni
- Re: [ietf-smtp] DSNs Sam Varshavchik