(wonder which of the IMAP lists would be the most appropriate for this..)
> Any of the following SEARCH command MUST NOT change the search result
> variable:
>
> o A SEARCH command that caused the server to return the BAD tagged
> response,
I think it's less dangerous to clear the variable. For example:
1 search return (save) all
2 fetch $ flags
3 search return (save) subject hello world
4 store $ +flags.silent \deleted
5 expunge
3 exposes a buggy client and returns BAD. 5 then expunges all messages.
> In some cases, the server MAY refuse to save a SEARCH (SAVE)
> result, for example if an internal limit on the number of saved
> results is reached.
I don't see the point, it just complicates the protocol. The result
can't be larger than the number of messages in a mailbox. The server has
to keep all kinds of data related to the messages already, so one search
result shouldn't be that big of a deal. I can think of two usable ways
to store the result, the worst case space usages would be:
1. Array of { uint32_t uid1, uid2 }: 2 * 4 * message_count bytes = 78kB
for 10000 message mailbox.
2. Bitmask of sequences: message_count/8 bytes = 1,2 kB for 10000
message mailbox.
Attachment:
signature.asc
Description: This is a digitally signed message part