From nobody Mon Nov 13 07:10:13 2017 Return-Path: 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 8DFA4129571 for ; Mon, 13 Nov 2017 07:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1r1rbbW35jF6 for ; Mon, 13 Nov 2017 07:10:05 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14843129A84 for ; Mon, 13 Nov 2017 07:10:05 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id g73so5360404ioj.8 for ; Mon, 13 Nov 2017 07:10:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zCzPS3cR/aWt1UHXEq45YMb1sMr7IP8DeAE/oMTnYO0=; b=DdRTy24H7HZV4wr+3jdgVqeflu0b8RDEBbPPd6Ezm2cpW5GotuCvgF1Sgl+7JEBebJ ovMOEnhBQI+Beo7P1D6/z7pMSizPmILK/EliEX75eVeJ53HQ2yN0+5KRo54E2Vd6wtfw hyDI3vdNAEYrzXyNPRT2bWpOpyivfmAviLbhsFuDG00eLs3uDw+XeajXDb7XMbZrQ0Fk n4EHOnBqX/Lu/PmE7D+P/5p8UKqYtHLq8r03GjIJVWKkCXVsHCAFdlCuHX7vMsKqVOpZ zzghEqKNHZdDnCGYBAwH9fTOBo6e8UuXAi40Y0jBLetxclyJKau1Mu+RRDNHKzpAp/DV ZjOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zCzPS3cR/aWt1UHXEq45YMb1sMr7IP8DeAE/oMTnYO0=; b=iRPU1Fx9PsLhl4KSJyCegjvBb88yesZ6itdCony+V8yikOTQMIQ1Q6U/JvxVnnjee/ TE1JVi58vRJC157WxhhgufKfpZ8F2B3H1NUBhCEVa98GLAXy4Fg0emN08xSUkoi/Az0o 0Fo7WII+OYL8PGHE+Pt5F3rcAt6pZyTaUbNW+MIFc0USV/29u67cjvB0BjIfn5i4WXJl 5OcHU2W+rLhVbPSmQoEye8MMa2URLMhuh7jnr03IQWpG2xypnZGETRw/QmPSB2TO19zQ /BXCLqMpoxC1q3CtL8+mcN+DmJ6EXDjgiUtZ4wIk2eWOQkNTsPCj0vpF329BprKrOLCW cHow== X-Gm-Message-State: AJaThX5KMZt34v97JhQthvzk+Xr3YJjoscdIU5QXDfPeiZ7Pryi/+sL8 /0xyWM1JzB/+ru8bY154WGCe+X7GRD/JXkTj7XVHQw== X-Google-Smtp-Source: AGs4zMY3/rz6HzH5nT/Q2ZClcEKYS7vunqh0yUB8zDrVs/i7Hi2+YM/VbbRl/91sUex6SiyOFtogiphUIpX6HMjXhnI= X-Received: by 10.107.178.135 with SMTP id b129mr559442iof.276.1510585804073; Mon, 13 Nov 2017 07:10:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.31.3 with HTTP; Mon, 13 Nov 2017 07:10:03 -0800 (PST) From: vaibhav singh Date: Mon, 13 Nov 2017 20:40:03 +0530 Message-ID: To: imapext@ietf.org Content-Type: multipart/alternative; boundary="001a114c9d0c412f9f055ddeaabd" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:10:11 -0000 --001a114c9d0c412f9f055ddeaabd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, In order to optimize the way attachments inside encrypted mail are treated by the MUA, I am suggesting the registration of a "$HasEncryptedAttachment" to the IMAP Keywords registry[RFC5788]. Please find details of the original proposal below: > Type of Assignment: > Requesting for addition of a keyword "$HasEncryptedAttachment" to the > IMAP Keywords registry[RFC5788]. > > Registry: > The registration request is being made for IMAP Keywords > registry[RFC5788]. > > Description: > This flag can be useful so that the MUA can display an attachment > icon when displaying > messages in the folder, without it having to decrypt the message. > This flag can also be used to filter > encrypted emails with attachments. > > Additional Info: > The $HasEncryptedAttachment IMAP keyword will be used by IMAP/JMAP > MUA to > specify that the marked encrypted message contains an attachment. > A MUA-with-keys > sets this keyword when it sees a message having an attachment > before encryption. > This flag can be useful so that the MUA can display an attachment > icon when displaying > messages in the folder, without it having to decrypt the message. > This flag can also be used to filter > encrypted emails with attachments. > > Once set, any entity (be it the MDA or receiver's MUA) SHOULD not edit > the flag. > > JMAP Message Stores SHOULD be able to store the > $HasEncryptedAttachment keyword. > They MUST preserve it on the COPY operation. The servers MUST > support the SEARCH KEYWORD $HasEncryptedAttachment. Please find comments by Mr. Barry Leiba, and my answers below (marked as ): 1.) There should also be a =E2=80=9Chas no attachment=E2=80=9D keyword, so = the MUA doesn=E2=80=99t have to check either way and only needs to check if neither is set. Agreed. 2.) The keyword is poorly named: it=E2=80=99s not about an encrypted attach= ment, but about any attachment. I suppose that in the end there no reason to mention encryption at all, because it could be used for any message, though it=E2=80=99s less important for unencrypted ones. Not really sure. 3.) How will the server know to set the keyword? The server also can=E2=80= =99t decrypt an incoming message, and so it can=E2=80=99t check. Where does the knowledge come from? It seems that it could only work for messages that are created locally, with the keyword set at creation. A better use case for the flag could be: the server could set this flag to true when it sees the mime being decrypted the first time, so that any scans later on would not have to decrypt the mail again to know the presence of the attachment inside it Will this be useful? --=20 Regards, Vaibhav Singh --001a114c9d0c412f9f055ddeaabd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

In order to optimize the way= attachments inside encrypted mail are treated by the MUA, I am suggesting = the registration of a "$HasEncryptedAttachment" to the IMAP Keywo= rds registry[RFC5788].

Please find details of the original pro= posal below:

> Type of Assignment:
>=C2= =A0 Requesting for addition of a keyword "$HasEncryptedAttachment"= ; to the
> IMAP Keywords registry[RFC5788].
>
> Registry:=
> The registration request is being made for IMAP Keywords
> r= egistry[RFC5788].
>
> Description:
>=C2=A0 =C2=A0 =C2=A0T= his flag can be useful so that the MUA can display an attachment
> ic= on when displaying
>=C2=A0 =C2=A0 messages in the folder, without it = having to decrypt the message.
> This flag can also be used to filter=
>=C2=A0 =C2=A0 encrypted emails with attachments.
>
> Ad= ditional Info:
>=C2=A0 The $HasEncryptedAttachment IMAP keyword will = be used by IMAP/JMAP
> MUA to
>=C2=A0 =C2=A0 specify that the m= arked encrypted message contains an attachment.
> A MUA-with-keys
= >=C2=A0 =C2=A0 sets this keyword when it sees a message having an attach= ment
> before encryption.
>=C2=A0 =C2=A0 =C2=A0This flag can be= useful so that the MUA can display an attachment
> icon when display= ing
>=C2=A0 =C2=A0 messages in the folder, without it having to decry= pt the message.
> This flag can also be used to filter
>=C2=A0 = =C2=A0 encrypted emails with attachments.
>
> Once set, any ent= ity (be it the MDA or receiver's MUA) SHOULD not edit
> the flag.=
>
> JMAP Message Stores SHOULD be able to store the
> $H= asEncryptedAttachment keyword.
> They MUST preserve it on the COPY op= eration.=C2=A0 The servers MUST
> support the SEARCH KEYWORD $HasEncr= yptedAttachment.

Please find comments by Mr. Barry= Leiba, and my answers below (marked as <vs>):

1.) There should also be a =E2=80=9Chas no attachment=E2=80=9D keyword, = so the MUA doesn=E2=80=99t have to check either way and only needs to check= if neither is set.
=C2=A0=C2=A0
=C2=A0<vs>= =C2=A0 Agreed. </vs>

2.) The keyword is poor= ly named: it=E2=80=99s not about an encrypted attachment, but about any att= achment.=C2=A0 I suppose that in the end there no reason to mention encrypt= ion at all, because it could be used for any message, though it=E2=80=99s l= ess important for unencrypted ones.

=C2=A0<= ;vs> Not really sure. </vs>

3.) How will = the server know to set the keyword?=C2=A0 The server also can=E2=80=99t dec= rypt an incoming message, and so it can=E2=80=99t check.=C2=A0 Where does t= he knowledge come from?=C2=A0 It seems that it could only work for messages= that are created locally, with the keyword set at creation.
=C2= =A0
=C2=A0 <vs> A better use case for the flag could be: th= e server could set this flag to true when it sees the mime being decrypted = the first time, so that any scans later on would not have to decrypt the ma= il again to know the presence of the attachment inside it </vs>
=

Will this be useful?

--

Regards,
Vaibhav S= ingh
--001a114c9d0c412f9f055ddeaabd-- From nobody Tue Nov 14 00:25:33 2017 Return-Path: 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 171F9129A96 for ; Tue, 14 Nov 2017 00:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 1Seu-kExw9vj for ; Tue, 14 Nov 2017 00:25:28 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80ABB128D19 for ; Tue, 14 Nov 2017 00:25:28 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 47A4FFA0076; Tue, 14 Nov 2017 08:25:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1510647925; bh=rCzNKEhXzLq7nLFMUHX5jomC07AFjNlfafWJyEMC2To=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZgGyKcnd2I25oZ3NWATXdaATZI9v2C9HC3MAwiNcNnKkEPdkUagqPenWSnTVOeXYH BIMsJzQeQpVQavXWVvg5LuATxoXAExsHhaRcxRfZuH2WcPpaD4NnD/nE+wrgeH3PVa HK3zqxRKoiyqMj3kcJGfWrQ6f3Al00wVydKqEhTk= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1510647924-20834-22429/11/24; Tue, 14 Nov 2017 08:25:24 +0000 From: Arnt Gulbrandsen To: vaibhav singh Cc: imapext@ietf.org Date: Tue, 14 Nov 2017 08:25:23 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:25:30 -0000 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? Arnt From nobody Tue Nov 14 06:07:02 2017 Return-Path: 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 00F00120713 for ; Tue, 14 Nov 2017 06:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=l0HpylwD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=U/4jLz6O 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 yKS5VLIlzmmU for ; Tue, 14 Nov 2017 06:06:59 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FE41200E5 for ; Tue, 14 Nov 2017 06:06:59 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9146120C7A for ; Tue, 14 Nov 2017 09:06:58 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Tue, 14 Nov 2017 09:06:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jlcPDOZliml6ru73h kg2Pj2nQMsnSGfFwsRY7nPEdQc=; b=l0HpylwDPGkbcU6PGM41DJdlfqwR29HLY hYWHwxIt/zAJG5+iUjWHwQ/UvbswFxQjmL8V8ru2ilRbEhYUWM5DOGoPh6z4DQYy j3vfYNSBwrx/rorjG0QDDTIJmaDo6BFuoQZ6K78BwdzhofKd6ALF7KLiNXYznsj2 xOEuFePSJq96cpQrOpJsgMCLJBcafyZ/bsx8nUWS0xP4OCjSxuzQgH9KcQLpZeO4 vc2XnVvco0V4HjiCiCTlAkYw3+eHcFodYMOvNdMMhO9lPgO9i1lU2SeR809gFVEn uN5+AUoZJVYs0NgA6WszZgwfdDebaDjYhirUAyyuj92sThC89xLcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jlcPDO Zliml6ru73hkg2Pj2nQMsnSGfFwsRY7nPEdQc=; b=U/4jLz6OuZvxkUg1W0aAiV 7bbZfpJDViTzU9kQTrwqHBEBIEyfpYlsjPctnp6EyxnxLS+h+aHF4FcVLquyMYB0 fCQJyrAsNgYCaKI5Jw8Rb/KxwK9yTZz661ujYxlz5ml6GxcNBqEq4NUxPs4c60EE o7Qu0+hVIt7nWRSN7XUpK4JEiVSNL/b2DsB8NwHccH5bqWgxsFzjlbW6n0ZP0sSo 5dfRoVcUHtotZInFY/uNbkIu4KTD/6Nivk5ozh3SQgwsPgUR7Ouz7WqK/LQ7vWe6 cBDQ+IWOplFHLSiGBJlYca152sOInqlE0AQSCiumFnR3nYRGhPe0grL9rocmbzBQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 62CAD48020; Tue, 14 Nov 2017 09:06:58 -0500 (EST) Message-Id: <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com> From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15106684187678160" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9 In-Reply-To: References: Date: Wed, 15 Nov 2017 01:06:58 +1100 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 14:07:01 -0000 This is a multi-part message in MIME format. --_----------=_15106684187678160 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" 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. There are questions about that being a metadata leak that haven't been addressed. 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. 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. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15106684187678160 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

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.

There are questions about that being a metadata leak that haven't been addressed.

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.

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.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_15106684187678160-- From nobody Tue Nov 14 06:25:16 2017 Return-Path: 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 87BDB126DC2 for ; Tue, 14 Nov 2017 06:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 iSoIfHD31Fvu for ; Tue, 14 Nov 2017 06:25:11 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB4E124C27 for ; Tue, 14 Nov 2017 06:25:10 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 68578FA0076; Tue, 14 Nov 2017 14:25:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1510669509; bh=Cl3bmIZbWfXWF+EiuaQ8jtk89Ro/HhxbpthRUsGVncQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XCX71DnMWkWQ8qMYZ+OqcCRUuSXEudTweWNmbTT80RmyG3A7O9G6P+kwoNY3dhvKh c9MsMCOCGlg/n02BTXnIZCRFH8jXFFdmDNSyAxwM2R33Po9qSmN7qemsxMFr9zJz9R hEv+XuHwZKRBf+3Hs7JT4i2l6UM8Aen+Z23MV7vA= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1510669508-22432-22429/11/26; Tue, 14 Nov 2017 14:25:08 +0000 From: Arnt Gulbrandsen To: imapext@ietf.org Date: Tue, 14 Nov 2017 14:25:06 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <914700fa-473e-422a-9bda-d22c9afabba5@gulbrandsen.priv.no> In-Reply-To: <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com> References: <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 14:25:14 -0000 Bron Gondwana writes: > 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. Oh, right. > There are questions about that being a metadata leak that > haven't been addressed. I thought about those and it seems insignificant. The size of the encrypted blob is a good proxy for that information anyway. Big? Attachment. Small? No. > Anyway, I don't think the whole way this would work has been > well thought out yet. AOL. It would seem to serve the case where the user uses two clients, both of which display whether a message has an attachment and neither of which displays any other information from inside the blob. In particular, neither can display an excerpt of the text, or any information about the kind of attachment. Arnt From nobody Tue Nov 14 06:58:52 2017 Return-Path: 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 4A9A2124C27 for ; Tue, 14 Nov 2017 06:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rKUJn43dI7_X for ; Tue, 14 Nov 2017 06:58:46 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (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 CA7D112426E for ; Tue, 14 Nov 2017 06:58:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 01DF782010E4; Tue, 14 Nov 2017 09:58:46 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0iVM5J8Kzlp; Tue, 14 Nov 2017 09:58:45 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id A89C082010D5; Tue, 14 Nov 2017 09:58:44 -0500 (EST) Date: Tue, 14 Nov 2017 09:58:42 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen , imapext@ietf.org Message-ID: <5E5BABB0AC20B6710541DF4D@caldav.corp.apple.com> In-Reply-To: <914700fa-473e-422a-9bda-d22c9afabba5@gulbrandsen.priv.no> References: <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com> <914700fa-473e-422a-9bda-d22c9afabba5@gulbrandsen.priv.no> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1376 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 14:58:50 -0000 Hi Arnt, --On November 14, 2017 at 2:25:06 PM +0000 Arnt Gulbrandsen wrote: >> Anyway, I don't think the whole way this would work has been >> well thought out yet. > > AOL. It would seem to serve the case where the user uses two clients, > both of which display whether a message has an attachment and neither of > which displays any other information from inside the blob. In particular, > neither can display an excerpt of the text, or any information about the > kind of attachment. > I think a much more useful option would be for the first client to decrypt the blob and generate an IMAP-like BODYSTRUCTURE which it then encrypts to the user's public key and uploads as metadata attached to the original message. Then other clients which have the private key can grab the metadata and decrypt it to get the full structure of the encrypted blob. That way the clients get to learn a lot more about the message than the mere fact it contains an attachment. Note, that it might also be useful to send the encrypted BODYSTRUCTURE data as a separate part/header in the encrypted message. That way recipients would also gain the benefit of being able to quickly determine what the message contains. Of course that additional data does potentially leak some information about the message, but that might be acceptable. -- Cyrus Daboo From nobody Tue Nov 14 16:17:55 2017 Return-Path: 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 2EB4E128896 for ; Tue, 14 Nov 2017 16:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=tNsRVhb3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ez35c9yQ 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 27lW6n1WVwwI for ; Tue, 14 Nov 2017 16:17:51 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1A0127369 for ; Tue, 14 Nov 2017 16:17:51 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DC76420C6D for ; Tue, 14 Nov 2017 19:17:50 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Tue, 14 Nov 2017 19:17:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=NR4q9gq1VFG1Xhffl 8y9GzuNDPaR9ZTJS2ZJL3f6P5k=; b=tNsRVhb3JVbPtqMc2OTuN8XomaTwNcoqV Bn1zPcfvFj6Z244atr8ipDwf9S/mSoQwcUFl8pSYcWgT06fgKml3vpLXuWnnzl8a Cf/aAQQqCWAikvbpMmi762WicrnCcX8vSmWllbjkx+o/dxyAn3e+ggjSS42kxCeq ZZHC14qeFRDxk59zcD/zKIVZByIyqkCzH29zhLbVlhqBhbewMxY6CRs5l4AQCfGn aRDYhEVpiz8it3ll7HO5NGpM4qTqyJjC54tJO4An3AMtIJpin5WhWlExUZUMoGQj u7ULX5WG3Uaxu+68QcBKLBbfduBLDYOaJKdFgdo4dEt9JSVSRH/sQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=NR4q9g q1VFG1Xhffl8y9GzuNDPaR9ZTJS2ZJL3f6P5k=; b=ez35c9yQN9nU6hwMXQSjYt aJ+Zasc2mbacQdyX0xfH6swt6WOEA0gPUM5nZRS4ulzGM4P1roOSC71BC0HNGp3D xsIuDCZ4QDkkMVO8jcxiwEACcg23QFs1oc9SdlMp+A/KubWiIWuSeFDalB0rMWX4 CDcLoq+oCq+2IAd2X9ajiG8tZgjcIBiSFUtm3dFPWkeN91VCUfhottk6opyIljFz wHXqVgIMppHxblKCY9PzovRIdZ0Gve0whE/Af8UtoTY03C88lQH9aGRBCZmE0xOd chxmNAhaE8l5NoDOGHfapDhLN+i6REqwo1I/Za6HYD8TijxmQqWYHCo5Qg6mLrPA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B7EE048020; Tue, 14 Nov 2017 19:17:50 -0500 (EST) Message-Id: <1510705070.1780599.1172765248.174C2DDF@webmail.messagingengine.com> From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151070507017805990" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9 Date: Wed, 15 Nov 2017 11:17:50 +1100 References: <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com> <914700fa-473e-422a-9bda-d22c9afabba5@gulbrandsen.priv.no> <5E5BABB0AC20B6710541DF4D@caldav.corp.apple.com> In-Reply-To: <5E5BABB0AC20B6710541DF4D@caldav.corp.apple.com> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 00:17:53 -0000 This is a multi-part message in MIME format. --_----------=_151070507017805990 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 15 Nov 2017, at 01:58, Cyrus Daboo wrote: > Hi Arnt, > > --On November 14, 2017 at 2:25:06 PM +0000 Arnt Gulbrandsen > wrote: > >>> Anyway, I don't think the whole way this would work has been >>> well thought out yet. >> >> AOL. It would seem to serve the case where the user uses two clients,>> both of which display whether a message has an attachment and >> neither of>> which displays any other information from inside the blob. In >> particular,>> neither can display an excerpt of the text, or any information >> about the>> kind of attachment. >> > > I think a much more useful option would be for the first client to > decrypt > the blob and generate an IMAP-like BODYSTRUCTURE which it then > encrypts> to > the user's public key and uploads as metadata attached to the original> message. Then other clients which have the private key can grab the > metadata and decrypt it to get the full structure of the > encrypted blob.> That way the clients get to learn a lot more about the message > than the> mere fact it contains an attachment. > > Note, that it might also be useful to send the encrypted BODYSTRUCTURE> data > as a separate part/header in the encrypted message. That way > recipients> would also gain the benefit of being able to quickly determine > what the> message contains. Of course that additional data does potentially leak> some > information about the message, but that might be acceptable. The main value of any non-encrypted facts about the message (like a keyword about the attachment state) is to allow server-side search. I agree with Cyrus - the sender could easily attach the BODYSTRUCTURE as a separate encrypted part, though again that leaks information about the structure based on the size of the encrypted part - all sorts of side channel/metadata stuff needs to be thought through, and different people have different tradeoffs/risk profiles - but then most people don't want to think that deeply about every message they send, so if you make it too complex nobody will use it. Regardless of what gets stored encrypted or who does it however, the value of a keyword is search/sort. I still remain unconvinced that the usecase is common enough that any client would use it, particularly since the first client still needs to download the message so it can set the flag. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151070507017805990 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 15 Nov 2017, at 01:58, Cyrus Daboo wrote:
Hi Arnt,

--On November 14, 2017 at 2:25:06 PM +0000 Arnt Gulbrandsen

Anyway, I don't think the whole way this would work has been
well thought out yet.

AOL. It would seem to serve the case where the user uses two clients,
both of which display whether a message has an attachment and neither of
which displays any other information from inside the blob. In particular,
neither can display an excerpt of the text, or any information about the
kind of attachment.


I think a much more useful option would be for the first client to
decrypt
the blob and generate an IMAP-like BODYSTRUCTURE which it then encrypts
to
the user's public key and uploads as metadata attached to the original
message. Then other clients which have the private key can grab the
metadata and decrypt it to get the full structure of the encrypted blob.
That way the clients get to learn a lot more about the message than the
mere fact it contains an attachment.

Note, that it might also be useful to send the encrypted BODYSTRUCTURE
data
as a separate part/header in the encrypted message. That way recipients
would also gain the benefit of being able to quickly determine what the
message contains. Of course that additional data does potentially leak
some
information about the message, but that might be acceptable.

The main value of any non-encrypted facts about the message (like a keyword about the attachment state) is to allow server-side search.

I agree with Cyrus - the sender could easily attach the BODYSTRUCTURE as a separate encrypted part, though again that leaks information about the structure based on the size of the encrypted part - all sorts of side channel/metadata stuff needs to be thought through, and different people have different tradeoffs/risk profiles - but then most people don't want to think that deeply about every message they send, so if you make it too complex nobody will use it.

Regardless of what gets stored encrypted or who does it however, the value of a keyword is search/sort.

I still remain unconvinced that the usecase is common enough that any client would use it, particularly since the first client still needs to download the message so it can set the flag.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_151070507017805990-- From nobody Tue Nov 14 18:43:31 2017 Return-Path: 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 6F084127010 for ; Tue, 14 Nov 2017 18:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 r3yuG_ynnYBx for ; Tue, 14 Nov 2017 18:43:27 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1CA1201F2 for ; Tue, 14 Nov 2017 18:43:26 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id 8so31265879qtv.1 for ; Tue, 14 Nov 2017 18:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=I4wDLOWmq/tS0dZjzIofrc/JpasVeTjKUY2iUWkUoio=; b=Cc1iYcdGDjR82bWl4I5XRVgeDB8sHjFTTyHNKEcC4Mq/dEfscoweQe8e2sjfikLkN7 rZ7x1bFBKPY9meK4Q2wHejd+jQu2UjdCce02rk6ab8Hib3RpjjP1A9ZhvZ46erYKfFgb OMLPTD4Il0HLgM/fh/wFx0SI81zzv+p6pcZ71cRbK3eFsVMy0bgWUEqd5ZflF9wj9PQZ 1bswtAU99K8+vYYGMwFER3WL4a8zsfMXFxCKuNkAt4HJ/zoObWuErfVKiCramAPJmBSB fSYkfYlZfOpeViEubQUVXYeV1zaKlFbs4KRkumDXEwQllaNgi/j+hQjZ1p2McMG5BLvY rwfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=I4wDLOWmq/tS0dZjzIofrc/JpasVeTjKUY2iUWkUoio=; b=dEIYBQ7WvxfPn6CPZzg+7JtRD3YRPOG7OH0vlPdoqdfQ7lo7qcFvxtyLcDbpIM32fg xzBGIRPr2qMbsKbFodie4ONzGOPHE/8RnbIYYObC5nLlKDcvQBdwDGN6kVBz3aGo3Zj3 Q6oT0yUO1Mq4GmZnh13SOYF3eoWpO74zF9wwc2uzKQ3YDa7vGeMMAqz9kaoHTbQ19ICk Sb5MFtYExwnqRdAzxf290+1VVMOAfzi5evwnZEHRxyyOp4io5h8elzHV1rDxlLXydUlq RZ4MbXEzXeM4Zv2Ka1s5NCUFhslwy1KTJo58/wXIBUNlTCwlH0vluKF0iPGAsOjkEsc2 tjeQ== X-Gm-Message-State: AJaThX709j7Cs+nv96m84W9vNxyMhth/mYMeysPBpGc0Ln0XbuQV4Dvx jjlRpjLEFFRwQ1+E5gmyJFljl1+WzG8ayMx6TzU= X-Google-Smtp-Source: AGs4zMawxAYLh+VmO+UesIc6hwFPmmXK6rPV+ElTkqojjmdZLU9KgXdZhFk5zKFG8jUJ0kPAd/gqDM1x0rJXYNZALOE= X-Received: by 10.200.7.135 with SMTP id l7mr20335012qth.122.1510713805953; Tue, 14 Nov 2017 18:43:25 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.20.131 with HTTP; Tue, 14 Nov 2017 18:43:25 -0800 (PST) In-Reply-To: References: From: Barry Leiba Date: Wed, 15 Nov 2017 10:43:25 +0800 X-Google-Sender-Auth: hTtlfgvyl_w691Q79WSGydE-L_A Message-ID: To: vaibhav singh Cc: "imapext@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:43:29 -0000 Vaibhav left off one significant bit of my review: 4. ...the term =E2=80=9Cattachment=E2=80=9D is a bit odd in today=E2=80=99= s usage. Messages may have multiple parts. Whether some or all of those parts appear to the user as =E2=80=9Cattachments=E2=80=9D depends upon the rendering. For = example, a two-part message that is multipart/alternative... is there an =E2=80=9Cattachment=E2=80=9D? How about a single-part message that is imag= e/jpeg, with no text at all? What about if I forward a message and the forwarded message is included as a separate message/rfc822 part rather than being included in the main text? Barry On Mon, Nov 13, 2017 at 11:10 PM, vaibhav singh wrote: > Hello, > > In order to optimize the way attachments inside encrypted mail are treate= d > by the MUA, I am suggesting the registration of a "$HasEncryptedAttachmen= t" > to the IMAP Keywords registry[RFC5788]. > > Please find details of the original proposal below: > >> Type of Assignment: >> Requesting for addition of a keyword "$HasEncryptedAttachment" to the >> IMAP Keywords registry[RFC5788]. >> >> Registry: >> The registration request is being made for IMAP Keywords >> registry[RFC5788]. >> >> Description: >> This flag can be useful so that the MUA can display an attachment >> icon when displaying >> messages in the folder, without it having to decrypt the message. >> This flag can also be used to filter >> encrypted emails with attachments. >> >> Additional Info: >> The $HasEncryptedAttachment IMAP keyword will be used by IMAP/JMAP >> MUA to >> specify that the marked encrypted message contains an attachment. >> A MUA-with-keys >> sets this keyword when it sees a message having an attachment >> before encryption. >> This flag can be useful so that the MUA can display an attachment >> icon when displaying >> messages in the folder, without it having to decrypt the message. >> This flag can also be used to filter >> encrypted emails with attachments. >> >> Once set, any entity (be it the MDA or receiver's MUA) SHOULD not edit >> the flag. >> >> JMAP Message Stores SHOULD be able to store the >> $HasEncryptedAttachment keyword. >> They MUST preserve it on the COPY operation. The servers MUST >> support the SEARCH KEYWORD $HasEncryptedAttachment. > > Please find comments by Mr. Barry Leiba, and my answers below (marked as > ): > > 1.) There should also be a =E2=80=9Chas no attachment=E2=80=9D keyword, s= o the MUA doesn=E2=80=99t > have to check either way and only needs to check if neither is set. > > Agreed. > > 2.) The keyword is poorly named: it=E2=80=99s not about an encrypted atta= chment, but > about any attachment. I suppose that in the end there no reason to menti= on > encryption at all, because it could be used for any message, though it=E2= =80=99s > less important for unencrypted ones. > > Not really sure. > > 3.) How will the server know to set the keyword? The server also can=E2= =80=99t > decrypt an incoming message, and so it can=E2=80=99t check. Where does t= he > knowledge come from? It seems that it could only work for messages that = are > created locally, with the keyword set at creation. > > A better use case for the flag could be: the server could set this > flag to true when it sees the mime being decrypted the first time, so tha= t > any scans later on would not have to decrypt the mail again to know the > presence of the attachment inside it > > Will this be useful? > > -- > > Regards, > Vaibhav Singh > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > From nobody Tue Nov 14 18:55:21 2017 Return-Path: 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 B0C02129443 for ; Tue, 14 Nov 2017 18:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 72FbWqbCQAyb for ; Tue, 14 Nov 2017 18:55:16 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 259971294A6 for ; Tue, 14 Nov 2017 18:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1510714514; d=isode.com; s=june2016; i=@isode.com; bh=J3aq1xFZzJsq7FyDXr9N37J5XNnLf5ZlZL71RhmkEaQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=H4o9RqwkhdkbXp8xJQlbXR/wfVrJfAB2HQ4YPxUAKk+iOK33x2cBJbNZuEuaAwZxdt7rhg 9O33yopB6vkt4fPFSuXM+v8f38+0n5yEmuZ36urlp1mb/rRluljGLhWRuo16+GRUYynMaG r1ktR+umDc1yLAyFa6rnyR+ESB6wLxI=; Received: from [31.133.129.3] (dhcp-8103.meeting.ietf.org [31.133.129.3]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 15 Nov 2017 02:55:13 +0000 To: Barry Leiba , vaibhav singh References: Cc: "imapext@ietf.org" From: Alexey Melnikov Message-ID: <5A0BAC8D.8040308@isode.com> Date: Wed, 15 Nov 2017 10:55:09 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:55:20 -0000 On 15/11/2017 10:43, Barry Leiba wrote: > Vaibhav left off one significant bit of my review: >=20 > 4. ...the term =E2=80=9Cattachment=E2=80=9D is a bit odd in today=E2=80= =99s usage. Messages > may have multiple parts. Whether some or all of those parts appear to > the user as =E2=80=9Cattachments=E2=80=9D depends upon the rendering. For= example, a > two-part message that is multipart/alternative... is there an > =E2=80=9Cattachment=E2=80=9D? How about a single-part message that is ima= ge/jpeg, > with no text at all? What about if I forward a message and the > forwarded message is included as a separate message/rfc822 part rather > than being included in the main text? I think "Content-Disposition: attachment" is a good indicator of whether something is an "attachment". In absence of Content-Disposition any decision is an heuristic. > Barry >=20 >=20 > On Mon, Nov 13, 2017 at 11:10 PM, vaibhav singh > wrote: >> Hello, >> >> In order to optimize the way attachments inside encrypted mail are treate= d >> by the MUA, I am suggesting the registration of a "$HasEncryptedAttachmen= t" >> to the IMAP Keywords registry[RFC5788]. >> >> Please find details of the original proposal below: >> >>> Type of Assignment: >>> Requesting for addition of a keyword "$HasEncryptedAttachment" to the >>> IMAP Keywords registry[RFC5788]. >>> >>> Registry: >>> The registration request is being made for IMAP Keywords >>> registry[RFC5788]. >>> >>> Description: >>> This flag can be useful so that the MUA can display an attachment >>> icon when displaying >>> messages in the folder, without it having to decrypt the message. >>> This flag can also be used to filter >>> encrypted emails with attachments. >>> >>> Additional Info: >>> The $HasEncryptedAttachment IMAP keyword will be used by IMAP/JMAP >>> MUA to >>> specify that the marked encrypted message contains an attachment. >>> A MUA-with-keys >>> sets this keyword when it sees a message having an attachment >>> before encryption. >>> This flag can be useful so that the MUA can display an attachment >>> icon when displaying >>> messages in the folder, without it having to decrypt the message. >>> This flag can also be used to filter >>> encrypted emails with attachments. >>> >>> Once set, any entity (be it the MDA or receiver's MUA) SHOULD not edit >>> the flag. >>> >>> JMAP Message Stores SHOULD be able to store the >>> $HasEncryptedAttachment keyword. >>> They MUST preserve it on the COPY operation. The servers MUST >>> support the SEARCH KEYWORD $HasEncryptedAttachment. >> >> Please find comments by Mr. Barry Leiba, and my answers below (marked as >> ): >> >> 1.) There should also be a =E2=80=9Chas no attachment=E2=80=9D keyword, s= o the MUA doesn=E2=80=99t >> have to check either way and only needs to check if neither is set. >> >> Agreed. >> >> 2.) The keyword is poorly named: it=E2=80=99s not about an encrypted atta= chment, but >> about any attachment. I suppose that in the end there no reason to menti= on >> encryption at all, because it could be used for any message, though it=E2= =80=99s >> less important for unencrypted ones. >> >> Not really sure. >> >> 3.) How will the server know to set the keyword? The server also can=E2= =80=99t >> decrypt an incoming message, and so it can=E2=80=99t check. Where does t= he >> knowledge come from? It seems that it could only work for messages that = are >> created locally, with the keyword set at creation. >> >> A better use case for the flag could be: the server could set this >> flag to true when it sees the mime being decrypted the first time, so tha= t >> any scans later on would not have to decrypt the mail again to know the >> presence of the attachment inside it >> >> Will this be useful? >> >> -- >> >> Regards, >> Vaibhav Singh >> >> _______________________________________________ >> imapext mailing list >> imapext@ietf.org >> https://www.ietf.org/mailman/listinfo/imapext >> >=20 > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext >=20 From nobody Tue Nov 14 18:58:45 2017 Return-Path: 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 51473127863 for ; Tue, 14 Nov 2017 18:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8yAcDsBCd0h8 for ; Tue, 14 Nov 2017 18:58:42 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9B7127137 for ; Tue, 14 Nov 2017 18:58:42 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id f8so31308186qta.5 for ; Tue, 14 Nov 2017 18:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=MiMi/ZEhhczLetNAZo0ocSRRaxlYg9Ktc6uCI7pqepc=; b=oIoMqNZTSszypoqlBBdsYvy6auUXficqSRcD1+BG69CpvQt06vYwO7duds+x7u+v1T Ph6zxcptw3x9BJli9q+Fko25/r7kHh0tCg5rQ0lW9hhl032lboIFfGhcuvzD9KrFNXxm BpNqVSVHbYnVEMXFdn/jLkQKvPReOj+k20vytzQQ7wRrwZM8rvHy+ao76oNbRwQ4LraC bPqzDmHi4F3Jiq7zgcSzlZ9hYEz8AMt78D8mSHLA4GFwM3pWXXPqYfNMigjd0rQTCq5E 3VHd4Mmeidsn/g2Sp57jGRqPRz5T57SajiSim8n2wGTX41KCgppbT0xLS4khJFZgAfe0 ef5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=MiMi/ZEhhczLetNAZo0ocSRRaxlYg9Ktc6uCI7pqepc=; b=li/EtJKTv1dd4Z6KXcrl23jtWILBk6lc1uLK+FhG5ZQI9f1KsoM8OtmXr7SXe9t+wQ 6irxptR//uGjEkAPzRd4nnrDvFQJJrtY4PbPmwG7rk4bsyPTMVB7VVrwbrrXzNMSFaNp ekwFEYVI7PMQP4tHz7zcORkNLcwNYuMLfoSbPsRs0FrIqu2XPioH/YHkK1xK+dseD9uE JSwmERbjpSRmm5oPRRiHrkqipBylQyR5OCRF5FxZUakd/2NWFE05KyZ+Si/rM3OUTx/i eTLFysFyi8qcu5MKNaYzgjKwZuEE1q4VPJfxIsn/9A6nESA4AlvCi5ThD8eib9g3A5tl wi2g== X-Gm-Message-State: AJaThX7/dJEYOtGMnHVtRbRweySMlMmW4+Ar6kN8bgKoQpALS6WIlHXv WHTHXbrdLr6jeE4QgHTfXEKKz/pzOPrSQnPoDAI= X-Google-Smtp-Source: AGs4zMYFrow0odNhAe5far7QXBJHTvPyHYqUu4Ndep/KksjGAfg/4esubU1QlmJ4aWoQqRaD65W+jwW6F+zaks7Wf9I= X-Received: by 10.200.42.219 with SMTP id c27mr23820114qta.28.1510714721390; Tue, 14 Nov 2017 18:58:41 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.20.131 with HTTP; Tue, 14 Nov 2017 18:58:40 -0800 (PST) In-Reply-To: <5A0BAC8D.8040308@isode.com> References: <5A0BAC8D.8040308@isode.com> From: Barry Leiba Date: Wed, 15 Nov 2017 10:58:40 +0800 X-Google-Sender-Auth: LaiUYCDokxMuprrSAu0y5ASx4ZY Message-ID: To: Alexey Melnikov Cc: vaibhav singh , "imapext@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:58:43 -0000 >> 4. ...the term =E2=80=9Cattachment=E2=80=9D is a bit odd in today=E2=80= =99s usage. Messages >> may have multiple parts. Whether some or all of those parts appear to >> the user as =E2=80=9Cattachments=E2=80=9D depends upon the rendering. F= or example, a >> two-part message that is multipart/alternative... is there an >> =E2=80=9Cattachment=E2=80=9D? How about a single-part message that is i= mage/jpeg, >> with no text at all? What about if I forward a message and the >> forwarded message is included as a separate message/rfc822 part rather >> than being included in the main text? > > I think "Content-Disposition: attachment" is a good indicator of whether > something is an "attachment". In absence of Content-Disposition any > decision is an heuristic. Sure, but the use of Content-Disposition is sporadic and unreliable. I think that, basically, this issue speaks to a preference for the suggestion of storing a BODYPART parse on first use, and then being able to use that for optimization later. Barry From nobody Wed Nov 15 20:17:50 2017 Return-Path: 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 B758F128D86 for ; Wed, 15 Nov 2017 20:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZbYMDfIxmsKO for ; Wed, 15 Nov 2017 20:17:47 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74330127419 for ; Wed, 15 Nov 2017 20:17:47 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id x28so4360029ita.0 for ; Wed, 15 Nov 2017 20:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YFqnnzyDrspC0r9lw5FBGvt9698lyu4MUnQxDnXmzjA=; b=TIc9BBaxnVPGoiHRvuefkH9SCohWmddFPpEHoA3dr072SKifW8qXNpSzRdyJFbtXOo z0mgACeI8FBChXGTT+omRIGUwvklTAL62BJ36cBdNL9asn70qPMSIpoOGNXsoWogPoLS ToSh7dcINTCgRf3y/QrhEycO3rt6GlUGoIfep+2D3sM9ExfNEUCfwJL4JGDV8QEb16xQ CsF4F0jXx8AZxj+xYQaRO1NnRZe7V+9NA1IM+fiTkRRcYUa7MNiH65kgxo3Kr3mJN5lB FNy9X4m2mWS8ADhhO5JoxHU1tGbcyV7tXL+GQ1ZhIodZ+liFcCiYSXRiMqa0F5h4xlcy QvHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YFqnnzyDrspC0r9lw5FBGvt9698lyu4MUnQxDnXmzjA=; b=Va6Hs1tlw1pZNj/tAK4/9Hv/gDS/UzVgRHWwbhr4TIlehWuq1SkfjeBA/szdyuKL4t P3PyvXt7ABEkLryyyMP4yU67Y23rv0MoTTXM9JHnk+6zd9FnW5h1e87qlhqBQtqQJ3Is FCDuo0hneN1B6E57C5v0n7nKqupZpsC1djyOjLEZbPRvxS24RvrhFfvNJxELKSvfIRSA V/P/EqKEWFvJ8zYamUBcA0/rBydd1ikb8T+tdmMEumGGJBN4mhdBOCNQKzsZHdh5zJqe rFlBanCrbKRhGtkHHnTH1RAd3G1swM0Luu0HWuG+J1XcZtTsA80SCU1S/nAptwbcxUFH Nqwg== X-Gm-Message-State: AJaThX6TbtdL67wgL64ahS3RvoMAcT/bU2/01ubcp/4SmxoAFXIw9JEU wudmwgfBKixTKVk0YPupzrx9+jz+SUZWgDkF88E= X-Google-Smtp-Source: AGs4zMYl6KpcEEmzblusiKdfLV06/FQkUBaMMqz6TXdMNOJxzOfAiIG6apOObBTFebyDSkzWwHZjJXz1dsn+YrfiQzo= X-Received: by 10.36.244.69 with SMTP id u5mr894988iti.67.1510805866523; Wed, 15 Nov 2017 20:17:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.31.3 with HTTP; Wed, 15 Nov 2017 20:17:46 -0800 (PST) From: vaibhav singh Date: Thu, 16 Nov 2017 09:47:46 +0530 Message-ID: To: imapext@ietf.org Content-Type: multipart/alternative; boundary="f403045fc07cffb2a9055e11e651" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 04:17:50 -0000 --f403045fc07cffb2a9055e11e651 Content-Type: text/plain; charset="UTF-8" > ---------- Forwarded message ---------- > From: Bron Gondwana > To: imapext@ietf.org > Cc: > Bcc: > Date: Wed, 15 Nov 2017 01:06:58 +1100 > Subject: Re: [imapext] General Request for Assignment (imap-keywords) > (was: [JMAP] SMIME Attachments) > > 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. > > There are questions about that being a metadata leak that haven't been > addressed. > > 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. > > 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. > > Sorry if there has been some miscommunication from my side, of the server being the entity setting the flag. The flag will be set by the party having access to the decryption keys (almost always the MUA), but this information will be stored as part of the message meta information, intermediated by the server. Thanks, Vaibhav Anyway, I don't think the whole way this would work has been well thought > out yet. > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > Regards, Vaibhav Singh --f403045fc07cffb2a9055e11e651 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable




---------- Forwarded message ---= -------
From:=C2=A0Bron Gondwana <brong@fastmailteam.com>
To:=C2=A0imapext@ietf.org
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0We= d, 15 Nov 2017 01:06:58 +1100
Subject:=C2=A0Re: [imapext] General Reques= t for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)

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 a= n
encrypted attachment.

So my question is, what advantage does this provide over checking the<= br>
bodystructure?

The usecase is that the entire message is = encrypted as a single blob, but it contains an attachment.=C2=A0 The client= wants to mark that so that other clients know it has an attachment.

There are questions about that being a= metadata leak that haven't been addressed.

There are questions that Barry and I spoke= about briefly on Saturday about pairing it with a $HasNoEncryptedAttachmen= t or something so you can tell that it's been checked already, which le= d to a general discussion about paired keywords and what it means if they&#= 39;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.

But yeah, I'm pretty sure the intentio= n 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 th= e 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 th= e server setting the flag in Vaibhav's most recent email came from - th= e whole point in the original scenario is that the server doesn't know = anything about the content of the email.

Sorry if= there has been some miscommunication from my side, of the server being the= entity setting the flag. The flag will be set by the party having access t= o the decryption keys (almost always the MUA), but this information will be= stored as part of the message meta information, intermediated by the serve= r.

Thanks,
Vaibhav

Anyway, I don't think the whole way th= is would work has been well thought out yet.

Bron.

--
=C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd
=C2=A0 brong@fastmailteam.com




Regards,
Vaibhav Singh
--f403045fc07cffb2a9055e11e651-- From nobody Wed Nov 15 21:13:45 2017 Return-Path: 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 EF94F1201F2 for ; Wed, 15 Nov 2017 21:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neiljhaveri-com.20150623.gappssmtp.com 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 pIMS5AFddnLi for ; Wed, 15 Nov 2017 21:13:42 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306E2126B6D for ; Wed, 15 Nov 2017 21:13:42 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id x7so18800942pfa.1 for ; Wed, 15 Nov 2017 21:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AlVuvMLnmFbGeT4ahS/suHl1QowLdbJrV0WSoJW5Uxw=; b=lJkVlXI13wdabhjGCvFBfaxoV8VK8Rrjw+9w2DeFWX4y63N0x3u72HO31ljUznJidV xaaJ7r3SnLsJKjnPAoAGe6llhAtKYlOsn9BuI4F7CEp2qz61kswsrTIe8wtOeIaXhHad yBN8B5Axw4IA7u5CvTzeXjfbXOX/qqWvZrjxsCcXHeXpWJl36jK62x8Evws+uUyXV9dM qrO5Ehce77riAkynvR9T57RKdogc2HgQL/tvzGk8LOM1+pPL8h8PpDX3X+07KKoB8O2n g+AQWSScpM5En7ibOtu+xC/5o2q9ZPeaksTeGF3tys4tRoiWGKpA4O+SA7bR4/5E64Wd 9zmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AlVuvMLnmFbGeT4ahS/suHl1QowLdbJrV0WSoJW5Uxw=; b=sEr6yaqHs7/bp5vTWUtt2bi6g70JXaBkUKzlFM+1vHv62sw5DTA6Bt8Gyn2yVPsLHZ N4cqkg70drwitJg9XCM9pJJ5R0cc0K4tizIglld8JoxfuD6Jc+x/ntLx9uur3s2JlU2d XQcvEbnK4P5KeckWwxzXRUU205Ddk6r2rgBT0VgkoHE1EQRDpW96l4R+R4jo1+tkPizj oiMzFaRL5v0sOv1O6EWOO0lf9c4sxnIaLaGTSlVdkI/PCtPDTffqrrHeV0BeSBoANu2p 2kKzR1Upe0nI36yd3de545wvK0BTmWXIe4+WiS8pow6p4wrEGqZSv4dVLZS2+pU8Ut65 Tdkg== X-Gm-Message-State: AJaThX7pvoBbvMzPExXz3zUaRynPoqUd/ovBmsUxcwfxiOFNxPmun3yE BYGbwPH5amYnL9SI5c84fnC13Q== X-Google-Smtp-Source: AGs4zMZ6Sxc0mqX0pGCl3CKQ0YbHQL1Tzw1Mo8TnHdarnNYTDT/eXYpwhxDnVR5rEONNUavMaBA5xQ== X-Received: by 10.84.194.3 with SMTP id g3mr503360pld.374.1510809221505; Wed, 15 Nov 2017 21:13:41 -0800 (PST) Received: from [192.168.1.7] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id k8sm485578pgt.22.2017.11.15.21.13.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 21:13:41 -0800 (PST) From: Neil Jhaveri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_613F6718-30F4-4096-AEE3-686D87B87FA8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 15 Nov 2017 22:13:39 -0700 In-Reply-To: <1510705070.1780599.1172765248.174C2DDF@webmail.messagingengine.com> Cc: imapext@ietf.org To: Bron Gondwana References: <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com> <914700fa-473e-422a-9bda-d22c9afabba5@gulbrandsen.priv.no> <5E5BABB0AC20B6710541DF4D@caldav.corp.apple.com> <1510705070.1780599.1172765248.174C2DDF@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:13:44 -0000 --Apple-Mail=_613F6718-30F4-4096-AEE3-686D87B87FA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 14, 2017, at 5:17 PM, Bron Gondwana = wrote: >=20 > I still remain unconvinced that the usecase is common enough that any = client would use it, particularly since the first client still needs to = download the message so it can set the flag. I agree, I just don=E2=80=99t see the value of this being significant = enough, since it only helps the second+ client that comes along. If you are dealing with messages encrypted as a single blob, and want to = have a good user experience, you probably have to venture into = thick-client territory and proactively download/decrypt the message = locally anyways. Otherwise, how can you provide full-text body search, = or a UI with a message preview, as many clients seem to be doing = nowadays? Doesn=E2=80=99t that also diminish the need for this keyword? Have I missed some important use-case?= --Apple-Mail=_613F6718-30F4-4096-AEE3-686D87B87FA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 14, 2017, at 5:17 PM, Bron Gondwana <brong@fastmailteam.com> wrote:

I still remain unconvinced that = the usecase is common enough that any client would use it, particularly = since the first client still needs to download the message so it can set = the flag.

I = agree, I just don=E2=80=99t see the value of this being significant = enough, since it only helps the second+ client that comes = along.

If you = are dealing with messages encrypted as a single blob, and want to have a = good user experience, you probably have to venture into thick-client = territory and proactively download/decrypt the message locally anyways. = Otherwise, how can you provide full-text body search, or a UI with a = message preview, as many clients seem to be doing nowadays?

Doesn=E2=80=99t that = also diminish the need for this keyword?

Have I missed some important = use-case?
= --Apple-Mail=_613F6718-30F4-4096-AEE3-686D87B87FA8-- From nobody Wed Nov 15 23:54:53 2017 Return-Path: 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 ; 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 ; 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 ; 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" To: "Bron Gondwana" Cc: imapext@ietf.org Date: Thu, 16 Nov 2017 01:54:42 -0600 Message-ID: In-Reply-To: <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com> References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.