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

[Michael Slusarz <[e-mail]>]

> On 09/24/2020 6:06 PM Benjamin Kaduk <[e-mail]> wrote:
> 
> On Tue, Sep 22, 2020 at 11:14:13PM -0600, Michael Slusarz wrote:
> > > On 09/22/2020 2:01 PM Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > >
> > >    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.
> > 
> > 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.
> 
> 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".

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