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

["Chris Newman" <[e-mail]>]

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.