commit 815822d81cd69814927013d24133aa2a0baa6179
parent 41308e481466b91813f6765a0c92ad83fd9d1ab2
Author: Oswald Buddenhagen <ossi@users.sf.net>
Date: Sun, 20 Nov 2016 11:47:09 +0100
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 ...
Diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/drv_imap.c b/src/drv_imap.c
@@ -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 );
