Re: [ietf-smtp] DSNs
Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 25 April 2020 01:36 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 30A883A1312 for <ietf-smtp@ietfa.amsl.com>; Fri, 24 Apr 2020 18:36:28 -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 Xah0WNPKYo3w for <ietf-smtp@ietfa.amsl.com>; Fri, 24 Apr 2020 18:36:25 -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 C5D153A1311 for <ietf-smtp@ietf.org>; Fri, 24 Apr 2020 18:36:25 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 522F84E745; Fri, 24 Apr 2020 21:36:24 -0400 (EDT)
Date: Fri, 24 Apr 2020 21:36:24 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf-smtp@ietf.org
Message-ID: <20200425013624.GV41308@straasha.imrryr.org>
Reply-To: ietf-smtp@ietf.org
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C1A5FAAA942E0F363CA177C0@PSB>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/MKsplDIjJssJWQmmsqYaGN8dsoA>
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 01:36:28 -0000
On Sat, Apr 18, 2020 at 07:10:21PM -0400, John C Klensin wrote: > > 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. Indeed much too strong, because IIRC support NOTIFY=SUCCESS is on by default in Postfix, and while I may make a point of turning it off "at the edge", that's likely not a common practice, and so success notifications likely work for a large fraction of internet-connected MTAs. > (1) Are DSNs implemented broadly enough that it is reasonable to > claim that the spec is good enough to allow interoperability? I don't recall seeing any reports of substantive DNS-interop issues on the Postfix-users list in the almost ~20 years that I've been an active participant. > (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. I also believe that DSNs are useful at least between a sending application to the edge MTA to acknowledge handoff from the sender's edge MTA toto the remote organization's edge MTA. Though similar data can be collected by providing log excerpts to applications, sometimes DSNs are easier to orchestrate. That said, NOTIFY=SUCCESS is not common. > (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. I am not aware of any substantive defects. > (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. Here, I would personally recommend to others not advertising DSN on receiving edge systems, and perhaps also ignoring its advertisement by remote edge systems. * Inbound, I do not want to offer SUCCESS notices, they leak data I'd prefer to not leak. Let the remote MTA send SUCCESS once I accept the message. The rest is none of their business. * Outbound, I can give a timely notification to internal senders that the message was delivered to the responsible organisation. I prefer to not delegate them to them a duty I'm unwilling to fulfil inbound, or to trust that they'll carry it out. -- Viktor.
- [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