Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-fetch-preview-09: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 22 Sep 2020 13:01:41 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-imap-fetch-preview-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Martin D's comment.

I was a little surprised to not see any mention of the analogous JMAP
capability (but I guess I'm not actually sure whether one or the other
"came first").

Section 3.3

   The server SHOULD limit the length of the preview text to 200 preview
   characters.  This length should provide sufficient data to generally
   support both various languages (and their different average word
   lengths) and diverse client display size requirements.

Does the internationalization directorate agree with this analysis?

   format, size, and filename.  This descriptive text is not a product
   of the message body itself but is rather auto-generated data by the
   server, and should thus use the rules defined for human-generated
   text described in the LANGUAGE extension (if supported on the
   server).

nit: is "human-generated text" the right description here?  A quick read
of RFC 5255 suggests that "generated for human consumption" is usually
the appropriate characterization of text affected by the langauge
selection.

Section 4.2

   Once this initial FETCH is complete, the client can then issue FETCH
   requests, without the LAZY modifier, to load the preview data for the

nit: "PREVIEW data item" would be more consistent with the previous
paragraph (and make it harder to skip over the fact that the preview
data is being FETCHed, not the entire message).

   messages in which preview data was not returned.  It is RECOMMENDED
   that these FETCH requests be issued in small batches, e.g. 50
   messages per FETCH command, since preview generation may be expensive
   and a single large request may exceed server resource limits.

nit: comma after "e.g.".

Section 5

I'd consider updating the dates in the examples to be closer to the
publication date of the document.

Section 8

Does it go without saying that a given user should only have access to
preview content for messages that it has access to the full content of?

   results are stored on the server after generation.  Servers MAY limit
   the resources that preview generation uses.  In order to mitigate

Would this result in the server generating empty-string previews for
some messages that it would otherwise have produced a non-empty preview
for?  I'd like to see a little more description of expected server
behavior in the case of excessive resource usage for preview generation.

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 23 Sep 2020 10:55:29 +1000

> capability (but I guess I'm not actually sure whether one or the other

It's already built into JMAP.  From RFC8621:

   o  preview: "String" (immutable; server-set)

      A plaintext fragment of the message body.  This is intended to be
      shown as a preview line when listing messages in the mail store
      and may be truncated when shown.  The server may choose which part
      of the message to include in the preview; skipping quoted sections
      and salutations and collapsing white space can result in a more
      useful preview.

      This MUST NOT be more than 256 characters in length.

      As this is derived from the message content by the server, and the
      algorithm for doing so could change over time, fetching this for
      an Email a second time MAY return a different result.  However,
      the previous value is not considered incorrect, and the change
      SHOULD NOT cause the Email object to be considered as changed by
      the server.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 Sep 2020 17:59:19 -0700

> It's already built into JMAP.  From RFC8621:

Exactly!  This is IMAP "catching up" to JMAP, at least in terms of
publication as an RFC.  If the JMAP feature was inspiration for the IMAP
feature, maybe that's worth remarking upon.

Thanks,

Ben

---

From: Michael Slusarz <[email-masked]>
Date: Tue, 22 Sep 2020 21:28:43 -0600 (MDT)

> On 09/22/2020 6:59 PM Benjamin Kaduk <[email-masked]> wrote:
> 

Author here: this draft stems from an internal feature that has been present in Dovecot since 2014.  It was initially accessible only through a Dovecot-specific API call; standardization was desired in order to provide a stable external API.
Thus, this draft was influenced by a previously existing feature and was not influenced by the JMAP implementation.

During discussions of this draft, we reconciled the definition of what a preview with respect to both JMAP and IMAP so that the same string could be used regardless of the protocol.  So implementation wise, we've done the legwork to ensure that the definitions are mutually compatible.

michael

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 Sep 2020 20:44:48 -0700

Hi Michael,

> During discussions of this draft, we reconciled the definition of what a preview with respect to both JMAP and IMAP so that the same string could be used regardless of the protocol.  So implementat…

Thanks for the extra background, and for putting in the effort to reconcile
with JMAP.  It seems we can chalk my surprise up to my ignorance (now
remediated).

-Ben

---

From: Michael Slusarz <[email-masked]>
Date: Tue, 22 Sep 2020 23:14:13 -0600 (MDT)

> On 09/22/2020 2:01 PM Benjamin Kaduk via Datatracker <[email-masked]> wrote:
>

Addressed in a separate message.

> capability (but I guess I'm not actually sure whether one or the other

Addressed in a separate message.

> the appropriate characterization of text affected by the langauge

Oops ... I think "human-generated" is just fundamentally wrong here.  We are discussing text that is meant for human consumption, but it is not generated BY humans (it's generated programmatically by the server).

My re-read of RFC 5255 indicates that "human-readable text" is the phrase that is used there.  And that's what we already use elsewhere in that paragraph.  So I think this is just a typo, and should be this:

  and should thus use the rules defined for human-readable text described in the LANGUAGE extension

> data is being FETCHed, not the entire message).

Agreed.

>    and a single large request may exceed server resource limits.

OK.

> publication date of the document.

Fair enough.  Although the old dates are a valuable lesson (at least to me) on how long it sometimes takes to move a draft through the process :)

> preview content for messages that it has access to the full content of?

The base IMAP4rev1 document doesn't even have this kind of warning.  If we think that this is necessary here then we should probably also push this idea to Alexey and Barry as they are working on the new IMAP revision, since this warning would apply to message data in general.

I don't believe this draft fundamentally changes anything in IMAP.  If you can access a mail in a mailbox, you can access its full body.  This extension just provides an alternative view of that body data, so it doesn't provide a novel way of accessing data.

> behavior in the case of excessive resource usage for preview generation.

For historical context: this is the exact issue that was discussed and addressed in the last draft (-09).  Previously, we would have allow a NIL response in this case that could have been returned in this situation.  However, we decided instead that a non-LAZY request must always return some sort of determinative response.

Preview data is "nice-to-have" info, as opposed to "must have" information like the actual message bodies.  As such, I feel it needs to be left up to the server to decide in extreme cases that it would rather provide no preview, which is an annoyance, than causing access to the mail data to be affected, which is a critical problem.

It may not be preview generation that is *causing* the excessive resource usage.  It could be the system is overloaded in general due to other problems.  The server is best positioned to determine which ancillary activities it may have to curtail in order to provide the basic mail access, and it is reasonable to predict that preview generation may be one of those activities.

As to what the expected server behavior should be?  I think that's dependent on the reasons behind the excessive resource usage.  The document defines a server's options: send nothing or send something less than a perfect preview.  The server should make the decision based on the information available to it; I don't think it's the job of this document to demand a specific kind of response.

michael

---

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Sep 2020 07:36:31 -0400

> The base IMAP4rev1 document doesn't even have this kind of warning.
>  If we think that this is necessary here then we should probably also
> push this idea to Alexey and Barry as they are working on the new IMAP
> revision, since this warning would apply to message data in general.
>
> I don't believe this draft fundamentally changes anything in IMAP.  If
> you can access a mail in a mailbox, you can access its full body.
>  This extension just provides an alternative view of that body data,
> so it doesn't provide a novel way of accessing data.

Put in terms of Ben's phrasing: Yes, it goes without saying.  There's
no partial access in IMAP: if you can do any FETCH command on a
message, you can do all FETCH commands on a message.  I don't think
anything further needs to be said.  We can consider whether it's worth
being more wordy about that in the imap4rev2 draft, which the IESG
should see fairly soon.  (I don't think more is needed there either,
but we can chat about that.)

Barry

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 23 Sep 2020 08:36:42 -0700

> but we can chat about that.)

Agreed, and sounds good.  ("You took the words right out of my mouth.")

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 Sep 2020 17:06:53 -0700

Hi Michael,

>   and should thus use the rules defined for human-readable text described in the LANGUAGE extension

+1, thanks

> Fair enough.  Although the old dates are a valuable lesson (at least to me) on how long it sometimes takes to move a draft through the process :)

Indeed ... you would probably not be surprised to find out how I have
learned that I should look for it.

> I don't believe this draft fundamentally changes anything in IMAP.  If you can access a mail in a mailbox, you can access its full body.  This extension just provides an alternative view of that bo…

[handled in a different thread]

> As to what the expected server behavior should be?  I think that's dependent on the reasons behind the excessive resource usage.  The document defines a server's options: send nothing or send somet…

I agree: we should not demand particular behavior.  I was wondering if we
wanted to give an example of server behavior without mandating it, e.g.,
"such resource limitations might, for example, cause a server to return a
preview that is the empty string for a message that otherwise would have
had a nonempty preview".

But it's not very important in the grand scheme of things and I won't push
further for it.

Thanks for the updates and explanations,

Ben

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 30 Sep 2020 22:33:07 -0600 (MDT)

> On 09/24/2020 6:06 PM Benjamin Kaduk <[email-masked]> wrote:
> 

I've come around to agreeing that there is little confusion if we can provide example behavior.

New text (split into 2 paragraphs):

      Implementation of this extension might enable denial-of-service
      attacks against server resources, due to excessive memory or CPU usage
      during preview generation or increased storage usage if preview results
      are stored on the server after generation. In order to mitigate such
      attacks, servers SHOULD log the client authentication identity on FETCH
      PREVIEW operations in order to facilitate tracking of abusive
      clients.

      Servers MAY limit the resources that preview generation uses. Such
      resource limitations might, in an extreme example, cause a server to 
      return a preview that is the empty string for a message that otherwise 
      would have had a non-empty preview. However, it is recommended that at
      least some preview text be provided in this situation, even if the
      quality of the preview is degraded.

michael