don't arbitrarily limit UIDs to a billion
the number was chosen to make queries more comprehensible when the server sends no UIDNEXT, but it appears that such insanely large UIDs actually show up in the wild. so send 32-bit INT_MAX instead. note that this is again making an assumption: that no server uses unsigned ints for UIDs. but we can't sent UINT_MAX, as that would break with servers which use signed ints. also, *we* use signed ints (which is actually a clear violation of the spec). it would be possible to special-case the range [1,inf] to 1:*, thus entirely removing arbitrary limits. however, when the range doesn't start at 1, we may actually get a single message instead of none due to the imap uid range limits being unordered. this gets really nasty when we need to issue multiple queries, as we may list the same message twice. a reliable way around this would be issuing a separate query to find the actual value of UID '*', to make up for the server not sending UIDNEXT in the first place. this would obviously imply an additional round-trip per mailbox ...
This commit is contained in:
parent
41308e4814
commit
815822d81c
|
@ -2300,7 +2300,7 @@ imap_load_box( store_t *gctx, int minuid, int maxuid, int newuid, int *excs, int
|
|||
imap_submit_load( ctx, buf, 0, sts );
|
||||
}
|
||||
if (maxuid == INT_MAX)
|
||||
maxuid = ctx->gen.uidnext ? ctx->gen.uidnext - 1 : 1000000000;
|
||||
maxuid = ctx->gen.uidnext ? ctx->gen.uidnext - 1 : 0x7fffffff;
|
||||
if (maxuid >= minuid) {
|
||||
if ((ctx->gen.opts & OPEN_FIND) && minuid < newuid) {
|
||||
sprintf( buf, "%d:%d", minuid, newuid - 1 );
|
||||
|
|
Loading…
Reference in New Issue
Block a user