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

[Alexey Melnikov <[e-mail]>]

On 15/11/2017 10:43, Barry Leiba wrote:
> Vaibhav left off one significant bit of my review:
> 
> 4.  ...the term “attachment” is a bit odd in today’s usage.  Messages
> may have multiple parts.  Whether some or all of those parts appear to
> the user as “attachments” depends upon the rendering.  For example, a
> two-part message that is multipart/alternative... is there an
> “attachment”?  How about a single-part message that is image/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
> 
> 
> On Mon, Nov 13, 2017 at 11:10 PM, vaibhav singh
> <[e-mail]> wrote:
>> 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
>> <vs>):
>>
>> 1.) There should also be a “has no attachment” keyword, so the MUA doesn’t
>> have to check either way and only needs to check if neither is set.
>>
>>  <vs>  Agreed. </vs>
>>
>> 2.) The keyword is poorly named: it’s not about an encrypted attachment, 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’s
>> less important for unencrypted ones.
>>
>>  <vs> Not really sure. </vs>
>>
>> 3.) How will the server know to set the keyword?  The server also can’t
>> decrypt an incoming message, and so it can’t 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.
>>
>>   <vs> 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 </vs>
>>
>> Will this be useful?
>>
>> --
>>
>> Regards,
>> Vaibhav Singh
>>
>> _______________________________________________
>> imapext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/imapext
>>
> 
> _______________________________________________
> imapext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/imapext
>