[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEARCHRES
Timo Sirainen wrote:
(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.
BAD response typically means that the server couldn't parse the command.
A server implementation might not even know that it was a SEARCH command.
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.
It makes no much difference. If we clear the response, the client can
issue "SEARCH NOT $" and produce the same result after that.
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.
Some reviewers wanted to have a way to handle DoS on SEARCHRES gracefully.
While this is allowed, it is up to server implementors to decide if the
server should ever do that.
Isode's server never do this.
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.