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