Re: [ietf-smtp] DSNs
John C Klensin <john-ietf@jck.com> Sat, 25 April 2020 22:41 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 8DD7F3A0C03 for <ietf-smtp@ietfa.amsl.com>; Sat, 25 Apr 2020 15:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6_V2rEvymASR for <ietf-smtp@ietfa.amsl.com>; Sat, 25 Apr 2020 15:41:22 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 BBE5B3A0C02 for <ietf-smtp@ietf.org>; Sat, 25 Apr 2020 15:41:21 -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 1jSTU2-000Fqo-Oq; Sat, 25 Apr 2020 18:41:14 -0400
Date: Sat, 25 Apr 2020 18:41:09 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, Ned Freed <ned.freed@mrochek.com>
cc: ietf-smtp@ietf.org, Viktor Dukhovni <ietf-dane@dukhovni.org>
Message-ID: <CCD9771E28F1C5438052BB1A@PSB>
In-Reply-To: <21987cb0-1cc2-e5ce-363f-5bb713333e8e@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>
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/jU2qcjeUEL_UowxdLlc9rsME9po>
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 22:41:25 -0000
--On Saturday, April 25, 2020 14:46 -0700 Dave Crocker <dhc@dcrocker.net> wrote: >... > First, I meant whether the feature worked, for whatever > reason. If operational policy prohibits its use, then it > doesn't work. Dave, I think this is where either your comments are still not clear (at least to me) or we disagree. Suppose there were correspondents, or even domains, for which I have found read receipts useful and something I'm willing to let them use. So, because of them, I advertise the availability of that feature in the EHLO response. When the MAIL command comes along and doesn't contain that domain or mailbox, I reject the request. Now, which mailboxes or domains to accept is an operational decision, but the behavior, AFAICT, is fully conforming and it certainly don't mean that the features doesn't work, just that I have an operational policy prohibiting its use in most circumstances. The security vunerability of that particular policy are obvious but, if I were to tighten them up to require the the identity of the sender be proven to my satisfaction, it wouldn't change the analysis. That exactly becomes particularly striking in the case of read receipt--type MDNs because, even if the delivery MTA advertises the feature and accepts the request, all it can do then is to pass the request on to the receiving MUA because only it knows whether the message was read (maybe a message body retrieval request to an IMAP server would be an adequate approximation, maybe not). Now there is an end user operational policy issue: "do I allow a read receipt to be sent to to particular sender?". That user may have any operational policy he or she fancies, including ones ranging sending receipts only to messages whose bodies have verifiable signatures to sending receipts only for messages that arrive between 10AM and 4PM on alternate Tuesdays and ignoring all others. Again, that doesn't have anything to do with the feature not working. Your statement above (at least as I interpreted it) would clearly be true (and the feature not workable for policy reasons) if operational policies were consistent all across the Internet, probably including uses of SMTP over VPNs or SDNs, and those policies never allowed the feature to be used, but counterexamples have already been given to any possible assertion about the policy condition is globally true. 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