Re: [imapext] General Request for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)

[vaibhav singh <[e-mail]>]

> ---------- Forwarded message ----------
> From: Bron Gondwana <[e-mail]>
> To: [e-mail]
> 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
>   [e-mail]
>
>
>
>
Regards,
Vaibhav Singh