Subject: [Extra] Suggestions on IMAP PARTIAL response

From: Vikram Nagulakonda <[email-masked]>
Date: Thu, 23 Dec 2021 19:06:12 +0000 (UTC)

Hi All
We are introducing MESSAGELIMIT capability and response code in IMAP PARTIAL RFC. IMAP PARTIAL RFC is enforcing message retrieval and update limits per imap request.

As per RFC, IMAP server will return NO with MESSAGELIMIT response code to clients using PARTIAL return options on FETCH & SEARCH imap requests.

For FETCH & SEARCH imap requests without PARTIAL return option, according to RFC the server will return messages up to the limit defined in capabilities along with an OK/MESSAGELIMIT response code.

We would like to keep the response for COPY, MOVE & STORE imap requests and wanted to get your opinions & suggestions. Do you think it is a good idea to perform a partial update and reply with OK/MESSAGELIMIT response code?

If you agree that it is ok to do a partial update, how should we return the MESSAGELIMIT response code on COPY as tagged COPY response includes COPYUID response code?

Looking forward to your suggestions.

Thanks
Vikram

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 26 Dec 2021 17:27:40 +0200

On 23. Dec 2021, at 21.06, Vikram Nagulakonda <nvikram=[email-masked]> wrote:
> 
> Hi All
> We are introducing MESSAGELIMIT capability and response code in IMAP PARTIAL RFC <https://datatracker.ietf.org/doc/draft-melnikov-imap-partial/>. IMAP PARTIAL RFC is enforcing message retrieval and update limits per imap request.

"Interaction between PARTIAL, MIN, MAX and SAVE SEARCH return options" matches how Dovecot v2.3.11+ behave (I think older versions just returned everything in $).

Should the non-UID FETCH command also support PARTIAL? It could be useful together with CHANGEDSINCE.

> For FETCH & SEARCH imap requests without PARTIAL return option, according to RFC the server will return messages up to the limit defined in capabilities along with an OK/MESSAGELIMIT response code.

I don't see how you can implement this MESSAGELIMIT for FETCH (and maybe SEARCH) without breaking existing IMAP clients. They will not be happy about partial fetch results, regardless of whether it's returning OK or NO. I'd think NO would be at least a bit better since it indicates that everything didn't work right.

You could of course make it optional by requiring client to ENABLE MESSAGELIMIT, but then why would any client ever do that?

I'm not sure what is the point of it anyway especially for FETCH? The server could just throttle the FETCH responses. Does it matter whether the client sends one FETCH command for 100k mails, vs 100 FETCH commands for 1k mails?

And how is MESSAGELIMIT supposed to work for SEARCH? Is it applying for the set of messages being searched, or the number of search results? I guess the former? What is client supposed to do if it receives this error? Again just do the same SEARCH but just in multiple commands, each with an extra seqset parameter for pagination?

FETCH and SEARCH can also return OK [EXPUNGEISSUED] if it skipped over some mails that were already expunged. This could conflict with the [MESSAGELIMIT].

> We would like to keep the response for COPY, MOVE & STORE imap requests and wanted to get your opinions & suggestions. Do you think it is a good idea to perform a partial update and reply with OK/M…

COPY is supposed to be atomic and not perform partial copies. MOVE could I guess, if it returns NO [MESSAGELIMIT].

> If you agree that it is ok to do a partial update, how should we return the MESSAGELIMIT response code on COPY as tagged COPY response includes COPYUID response code?

Existing clients aren't going to understand it anyway, so maybe * NO (TAG "...") [MESSAGELIMIT] similarly to ESEARCH. Or something similar.