#26 UID FETCH fails to fetch message

[Chongning Liao]

My university mail server apparently has uids starting from 1,000,000,000+ and does not provide useful infomation for the SELECT "INBOX" call. As a result mbsync's using "UID FETCH 1:1000000000" naturely never fetches a single message. A work around (as I discovered in offlineimap's way of doing it) is simply use "UID FETCH 1: (UID FLAGS)". But I am completely new to this code base and have no idea where to look into to fix it. Follows are outputs that demostrates the problem and solution.

First comes the output of mbsync -D

> > Opening master box INBOX...
> >>> 4 SELECT "INBOX"
> Opening slave box INBOX...
> * 848 EXISTS
> * 0 RECENT
> * OK [UIDVALIDITY 1] UIDs valid
> * FLAGS (\Answered \Seen \Deleted \Draft \Flagged)
> * OK [PERMANENTFLAGS (\Answered \Seen \Deleted \Draft \Flagged)] Limited
> 4 OK [READ-WRITE] SELECT completed
> Loading master...
> loading master [1,inf]
> >>> 5 UID FETCH 1:1000000000 (UID FLAGS)
> Loading slave...
> loading slave [1,inf]
> slave: 0 messages, 0 recent
> matching messages on slave against sync records
> 5 OK Fetch completed
> master: 848 messages, 0 recent
> matching messages on master against sync records
> Synchronizing...
> synchronizing old entries
> synchronizing new entries
> synchronizing flags
> propagating new messages

Then you can see how the fix should work in a telnet session.

> 0 select "INBOX"
> * 848 EXISTS
> * 0 RECENT
> * OK [UIDVALIDITY 1] UIDs valid
> * FLAGS (\Answered \Seen \Deleted \Draft \Flagged)
> * OK [PERMANENTFLAGS (\Answered \Seen \Deleted \Draft \Flagged)] Limited
> 0 OK [READ-WRITE] SELECT completed
> 1 uid fetch 1:* (uid flags)
> * 1 FETCH (UID 1414667100 FLAGS (\Seen))
> * 2 FETCH (UID 1414667101 FLAGS (\Seen))
> * 3 FETCH (UID 1414667102 FLAGS (\Seen))
> ... ... ... ...
> * 847 FETCH (UID 1414667962 FLAGS (\Seen \Answered))
> * 848 FETCH (UID 1414667963 FLAGS (\Seen))
> 1 OK Fetch completed

Regards, and BTW thank you for this great piece of software. It really feels neat and tidy.

[Chongning Liao]

After consulting https://tools.ietf.org/html/rfc3501#section-6.3.1 it seem that it is a failure to conforming to the standard on the server side. But the standard also suggest

If this[UIDNEXT] is missing, the client can not make any assumptions about the next unique identifier value.
So I think this is still a valid bug report.

[Chongning Liao]

Fixed it in an very ad hoc way: grep -R "1000000" through the repo -> found 2 occurences -> change both to "INT_MAX".

please let me know if you think this will break things hilariously.