From 815822d81cd69814927013d24133aa2a0baa6179 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Sun, 20 Nov 2016 11:47:09 +0100 Subject: [PATCH] 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 ... --- src/drv_imap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/drv_imap.c b/src/drv_imap.c index 608a2d3..4051ec6 100644 --- 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 );