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

[Bron Gondwana <[e-mail]>]

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
  [e-mail]