[ietf-smtp] draft-moore-email-addrquery (was Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>)
John C Klensin <john-ietf@jck.com> Tue, 16 February 2016 14:53 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D001A9177 for <ietf-smtp@ietfa.amsl.com>; Tue, 16 Feb 2016 06:53:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
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 F2lgfq9M_a62 for <ietf-smtp@ietfa.amsl.com>; Tue, 16 Feb 2016 06:53:41 -0800 (PST)
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 3B5821A9165 for <ietf-smtp@ietf.org>; Tue, 16 Feb 2016 06:53:41 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1aVh0S-0008Oa-A5; Tue, 16 Feb 2016 09:53:36 -0500
Date: Tue, 16 Feb 2016 09:53:31 -0500
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>
Message-ID: <848D74D495B18793FF18D264@JcK-HP8200.jck.com>
In-Reply-To: <56C31036.9000007@network-heretics.com>
References: <20160215192903.3510.qmail@ary.lan> <0962861D-5338-463C-8D3E-7D576E8FC883@dukhovni.org> <56C31036.9000007@network-heretics.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: <http://mailarchive.ietf.org/arch/msg/ietf-smtp/nRhcI8U0F3OCBZuyozJhHjJeqPI>
Cc: chris.newman@oracle.com, ietf-smtp@ietf.org
Subject: [ietf-smtp] draft-moore-email-addrquery (was Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>)
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 16 Feb 2016 14:53:45 -0000
(Moving to SMTP list because this is definition not about the DANE document in Last Call) --On Tuesday, February 16, 2016 07:04 -0500 Keith Moore <moore@network-heretics.com> wrote: >> Sadly Keith Moore's addrquery draft seems to have stalled: >> >> https://tools.ietf.org/html/draft-moore-email-addrquery-01 >> >> I agree that was a promising direction... Yes I quibbled over >> the details, but certainly not with the intention of blocking >> it, rather I wanted it to be more realistically deployable.. > It's not dead. I'm still working on it and will try to get a > revision out this coming weekend. Keith (and Chris), This is not a comprehensive review. I'll defer that until I see the revised version. However, some observations for you to consider: (1) While it is common on the Internet these days for bandwidth to be very inexpensive, that is not universally the case and, as the Internet reaches into more and more remote locations, may never be. Consequently, it may be desirable for a client to be able to specify the information it wants and perhaps whether it wants a non-error answer if that information is not available and/or whether it wants the server to trim information not on its list. Similarly, it may be useful for the server to be able to advertise at least a summary of the information it is willing to provide. If, for example, the client can determine that the server is unwilling (or unable) to supply recipient encryption information, it might not want to bother with the AQPX command. (2) I infer that, like VRFY and EXPN, a mail session (i.e., successful issuance of a MAIL command) is allowed but not required. You should say that explicitly. Also, even with weak authentication of the validity of a sender email address (or other credentials) I can easily imagine a server being willing to return some information to some senders from a given site but being less enthused about others. So there may be advantages to allowing either a mail session or a backward-pointing (as well as forward-pointing) address in the AQRY command. (3) At some level, as long as the "look at the first character only" rule and the theory of reply codes is not violated, I shouldn't care what new SMTP codes you add. On the other hand, because the theory of reply codes is fairly restricted and, as a result, the number of available codes smaller than might be obvious at first glance, I wonder if it is really necessary for you to invent (and use up) circa five new codes. Wouldn't it be better to assign (at most) three codes to this command and insist that servers and clients using it support and use extended reply codes? My recollection is that we have done that with some extensions in the past, so it isn't unprecedented. (4) The EAI WG went through a very long debate as to whether the right model was "if the server advertises the availability of the extension, go ahead and send non-ASCII characters in addresses if you like" and "the server much offer but the client has to explicitly request/indicate". While, IIR, the experimental version of those protocols allowed the former, experience and later discussions caused the WG to concluded that the second model was better. This spec seems to use the second model. Please at least review the EAI discussions before concluding that is a good idea and, ideally, explain why. (5) Finally, what is probably a bigger deal: I think I understand the reasons why you want to require a TLS session and an authenticated (rather than opportunistic) one at that. However, there will probably always be mailboxes on hosts that are never accessible by a single connection from a client machine on the public Internet and probably cases in which it is unwise to shadow user and key information onto more accessible hosts. For those systems, optimizing for, much less requiring, single-hop connections or tight timing dependencies may not be desirable. "Mail server on Mars" is one such example because simple round trip TCP (or DTN) time might exceed what would be considered a reasonable timeout for a database query on better-connected hosts. Personal concerns about privacy and address mining aside, little or none of the information AQPK is specified to return is actually highly sensitive. It seems to me that it might be better to relax that requirement, explain why it is desirable and/or use a "SHOULD" and explanation, but allow the normal multi-hop relay behavior of SMTP to work as it ordinarily does (presumably including DSN-style messages for the return data). Note that would allow end to end encryption with keys obtained through this mechanism and make it useful even in circumstances where hop-by-hop transport encryption is infeasible or provides little or no practical protection, so the advantages are considerable. Of course, servers could refuse to behave that way and it would probably be desirable for a client to be able that it is only interested in single-hop connection approaches, but those should perhaps by dynamic operational decisions rather than restrictions of the protocol. Again, those comments are for consideration -- some of them may be dumb ideas. But I'd like to think they deserve consideration and, if you decide to not reflect them in the spec, some discussion of why they are undesirable. best, john
- [ietf-smtp] draft-moore-email-addrquery (was Re: … John C Klensin