MailMate running a fetch with a negative ID - how do I reset?

Is the UID in MailMate field too small to hold the large UIDs generated by the server? ( a signed int, instead of unsigned int or something?)

It's Nov 9th 2022, and I'm still trying to track down this issue...

in which when MailMate tries to sync with the IMAP server it does a UID FETCH of a negative number.

I’m guessing that number is being generated from the last UIDNEXT and stored in a variable that is a Int32 but should be an UInt32 as evidenced below.

Some lines from my log:

22:51:19 S: * 0 RECENT
22:51:19 S: * OK [UNSEEN 28] First unseen.
22:51:19 S: * OK [UIDVALIDITY 1584965498] UIDs valid
22:51:19 S: * OK [UIDNEXT 2206296242] Predicted next UID
22:51:19 S: * OK [HIGHESTMODSEQ 7] Highest
22:51:19 S: D3 OK [READ-WRITE] Select completed (0.007 + 0.000 + 0.006 secs).
22:51:19 Condstore-based check (7 > 7) means fast synchronization is enabled
22:51:19 Attempting fast synchronization.
22:51:19 C: D4 UID FETCH -2088671054:* (UID)
22:51:19 S: D4 BAD Error in IMAP command UID FETCH: Invalid uidset (0.001 + 0.000 secs).
22:51:19 Error: Server response: “D4 BAD Error in IMAP command UID FETCH: Invalid uidset (0.001 + 0.000 secs).”.

Here the server states the next UID would be 2206296242.

Mailmate tries to do a UID FETCH -2088671054:* (UID)

2206296242 | 0 happens to equal -2088671054 which isn’t a coincidence, so there’s your overflow.

I’d assume it is when Mailmate stores the UIDNEXT from the previous session (it gets mangled) and then uses the mangled value in the new session to fetch new messages since the last session.

I also get this every so often. The server is a dovecot server and the only way to "fix" this is to delete all the dovecot files in my Maildir (dovecot-uidlist, dovecot.index.cache, dovecot.index.*, dovecot-uidvalidity*). Let me know I can get logs from Mailmate and I can provide them.

Could it be that the variable that stores UIDNEXT is a signed 32bit int instead of an unsigned 32bit int, and therefore when it processes the UIDNEXT and stores it in the variable it gets turned into a negative number. Then when it queries the server, it does a UID FETCH -UIDNEXT:* which then errors out by the server?

Thank you, Benny!

I had checked the IMAP RFC to see if the server was improperly generating UIDs https://datatracker.ietf.org/doc/html/rfc3501#section-2.3.1.1 It turned out that technically the IDs were out of range for a 32 signed int, but in range for an unsigned 32 int which is the definition of a "number" at the end of the rfc (0 <= n < 4,294,967,296)

Also, I've been harassing the ESP too because though they claim they reindex the INBOX, but the UIDs don't get reset, which also would have temporarily fixed the issue, or kicked the can until the next time it popped up.

I'm glad this item is fixable, and am happy I was able to contribute something to help make MailMate better.

Cheers!

Indeed, there wasn't that many messages that passed through that mailbox. Though my guess is that they may have generated the starting UID from a date string YYMMDDHHMM or something similar, and then kept counting from there, instead of bumping the UIDVALIDITY up.

Thank you so much for the quick fix!