Re: [imapext] General Request for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)
"Chris Newman" <chris.newman@oracle.com> Thu, 16 November 2017 07:54 UTC
Return-Path: <chris.newman@oracle.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C75129540 for <imapext@ietfa.amsl.com>; Wed, 15 Nov 2017 23:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YWeVX_YVGAKW for <imapext@ietfa.amsl.com>; Wed, 15 Nov 2017 23:54:50 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 C8B75120724 for <imapext@ietf.org>; Wed, 15 Nov 2017 23:54:49 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAG7siwh005285 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Nov 2017 07:54:45 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vAG7siEC005547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Nov 2017 07:54:44 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vAG7sidA000416; Thu, 16 Nov 2017 07:54:44 GMT
Received: from [192.168.33.76] (/38.133.201.145) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Nov 2017 23:54:43 -0800
From: Chris Newman <chris.newman@oracle.com>
To: Bron Gondwana <brong@fastmailteam.com>
Cc: imapext@ietf.org
Date: Thu, 16 Nov 2017 01:54:42 -0600
Message-ID: <EFC3F70C-67D5-47F7-BC78-0A9B38045CFB@oracle.com>
In-Reply-To: <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com>
References: <CACZ1GipM4+91KL00_YDcUHSF0eVnjh8vZAddbk869O4J1w9ZfA@mail.gmail.com> <c2f0b35e-1925-4769-9a22-c6663db1eb53@gulbrandsen.priv.no> <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.7r5425)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/Mc9YDF07uBujSLlsiFVw7dRiUwY>
Subject: Re: [imapext] General Request for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 07:54:52 -0000
On 14 Nov 2017, at 8:06, Bron Gondwana wrote: > On Tue, 14 Nov 2017, at 19:25, Arnt Gulbrandsen wrote: >> Hi, >> >> sorry about the late response. I suck at the moment. >> >> I don't understand the semantics here. >> >> If present, it means that someone has checked and found an encrypted >> attachment. And if absent, it means nothing. There may or may >> not be an> encrypted attachment. >> >> So my question is, what advantage does this provide over checking >> the> bodystructure? > > The usecase is that the entire message is encrypted as a single blob, > but it contains an attachment. The client wants to mark that so that > other clients know it has an attachment. Typically "has attachment" is a UI flag. For encrypted mail, the server can't provide that information so the client must if it's going to be provided. So clients wanting to present that UI flag have to parse encrypted messages. > There are questions about that being a metadata leak that haven't been > addressed. It is a deliberate leak of metadata. The nice thing about a leak of 1 or 2 bits of information is that the scope of the leak is largely understood. With an encrypted body structure, I'm more concerned about the scope of the information leak as it leaks non-obvious information. > There are questions that Barry and I spoke about briefly on Saturday > about pairing it with a $HasNoEncryptedAttachment or something so you > can tell that it's been checked already, which led to a general > discussion about paired keywords and what it means if they're both set > and wouldn't it be nice if we had tristate keywords and what about > per-message- > annotations and doesn't everything suck. This problem can be addressed by changing the definition as follows: $ClientSawAttachment => at least one client believes this message has an attachment. $ClientSawNoAttachment => at least one client believes this message does not have an attachment. If both are set, that now has a meaning (specifically that the end-user uses at least two different clients that have different opinions on what constitutes an attachment and whether the message has one :-). Basic guidelines for "has an attachment" calculations are: * Content-Disposition: attachment anywhere in the message means the message has an attachment. * If all parts have Content-Disposition: inline, that means the message has no attachment. For the following four guidelines, implementation-defined exceptions are permitted: * If the client can usefully render all MIME parts in a single view (and none are explicitly labelled an attachment), there's probably no attachment. * If there's a MIME part the client can't usefully render, there probably is an attachment. * multipart/related tends to imply that MIME subtree has no attachment unless the top-level type of the multipart/related is one the client can't render. * multipart/alternative tends to imply that MIME subtree has no attachment if at least one part is a text part the client can render. This is clearly somewhat heuristic when Content-Disposition is missing, but if the keywords are defined as above, I don't see a problem with that. I don't find this issue particularly important given how rarely encrypted email is used, but since there seems to be interest from more than one implementer, I don't see a compelling reason to block registration. - Chris > But yeah, I'm pretty sure the intention was just that clients would > use > it to communicate to each other something about the content of the > message inside the related opaque blob that is the message, in a case > where a user has multiple clients that all know how to decrypt the > message, but the server doesn't. > I have no idea where that most idea of the server setting the flag in > Vaibhav's most recent email came from - the whole point in the > original > scenario is that the server doesn't know anything about the content of > the email. > Anyway, I don't think the whole way this would work has been well > thought out yet. I can't say I find this a particularly useful extension but I think this can be documented with sufficient clarity that it serves the intended function well enough.
- [imapext] General Request for Assignment (imap-ke… vaibhav singh
- Re: [imapext] General Request for Assignment (ima… Arnt Gulbrandsen
- Re: [imapext] General Request for Assignment (ima… Bron Gondwana
- Re: [imapext] General Request for Assignment (ima… Arnt Gulbrandsen
- Re: [imapext] General Request for Assignment (ima… Cyrus Daboo
- Re: [imapext] General Request for Assignment (ima… Bron Gondwana
- Re: [imapext] General Request for Assignment (ima… Barry Leiba
- Re: [imapext] General Request for Assignment (ima… Alexey Melnikov
- Re: [imapext] General Request for Assignment (ima… Barry Leiba
- Re: [imapext] General Request for Assignment (ima… vaibhav singh
- Re: [imapext] General Request for Assignment (ima… Neil Jhaveri
- Re: [imapext] General Request for Assignment (ima… Chris Newman