Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08

[Timo Sirainen <[e-mail]>]

On 7. Jul 2020, at 6.22, Michael Slusarz <michael.slusarz=[e-mail]> wrote:
> 
>> On 07/02/2020 3:20 AM Timo Sirainen <[e-mail]> wrote:
>> 
>> 
>> On 2. Jul 2020, at 4.56, Bron Gondwana < [e-mail] <mailto:[e-mail]>> wrote: 
>>> As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version. 
>>> 
>>> This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication.  Please reply with any comments by Thursday, July 16th 2020.  Let's get this one off our plates before IETF108. 
>> 
>> 
>>    It is possible that preview text is not available now, but might be
>>    available later -- perhaps the server's preview-generating resources
>>    are overloaded, there is a server-imposed timeout during preview
>>    generation, or there is some transient issue with fetching the
>>    message body.  In such cases, the server will return NIL as the
>>    preview response, and the client can try to retrieve the preview
>>    later.
>> This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended.
> I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time.

I don't really see why this would be an issue. IMAP protocol doesn't have this kind of a special "DoS-prevention feature" anywhere else. Especially now that the preview is always text, I don't think it can be excessively slow to generate it. At least in Dovecot's implementation it's basically as expensive as fetching BODYSTRUCTURE, and we don't have DoS prevention against fetching those. Maybe in theory if server wanted to analyze attachments in some way .. but is it really worth the added complexity for a problem that probably will remain theoretical?

FETCH is also good in that it returns the results after each mail. So the server is allowed to start throttling the responses to the client without actually failing it.