Re: General Request for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)
Bron Gondwana <[email protected]> Wed, 15 Nov 2017 01:06:58 +1100
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com> |
This is a multi-part message in MIME format. --===============5446822548951588529== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15106684187678160" 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 [email protected] --_----------=_15106684187678160 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8" <!DOCTYPE html> <html> <head> <title></title> </head> <body><div style="font-family:Arial;"><br></div> <div>On Tue, 14 Nov 2017, at 19:25, Arnt Gulbrandsen wrote:<br></div> <blockquote type="cite"><div>Hi,<br></div> <div><br></div> <div>sorry about the late response. I suck at the moment.<br></div> <div><br></div> <div>I don't understand the semantics here.<br></div> <div><br></div> <div>If present, it means that someone has checked and found an encrypted<br></div> <div>attachment. And if absent, it means nothing. There may or may not be an<br></div> <div>encrypted attachment.<br></div> <div><br></div> <div>So my question is, what advantage does this provide over checking the<br></div> <div>bodystructure?<br></div> </blockquote><div><br></div> <div style="font-family:Arial;">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.<br></div> <div style="font-family:Arial;"><br>There are questions about that being a metadata leak that haven't been addressed.</div> <div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">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.<br></div> <div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">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.<br></div> <div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">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.<br></div> <div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">Anyway, I don't think the whole way this would work has been well thought out yet.<br></div> <div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">Bron.<br></div> <div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">--<br></div> <div id="sig56629417"><div class="signature"> Bron Gondwana, CEO, FastMail Pty Ltd<br></div> <div class="signature"> [email protected]<br></div> <div class="signature"><br></div> </div> <div style="font-family:Arial;"><br></div> </body> </html> --_----------=_15106684187678160-- --===============5446822548951588529== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext --===============5446822548951588529==--