MBOX-Line: From mrc at CAC.Washington.EDU  Wed Jan 24 18:25:11 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] Microsoft Outlook IMAP non-compliance: negative UIDs
Message-ID: <alpine.LRH.0.82.0701241824421.30514@shiva1.cac.washington.edu>

Microsoft Outlook sends a
    	tag UID FETCH n:* ...data items....
command shortly after opening the mailbox.  This is the typical idiom for 
learning about messages that were delivered since the mailbox was last 
opened, with n being the largest UID determined in the previous session 
plus 1.

There's a problem, though.  Outlook sends n as a *signed* value.  The IMAP 
specification (RFC 3501) is very specific that UIDs are unsigned non-zero 
32-bit values.

Thus, Outlook ends up sending:
    	5mwd UID FETCH -1065616957:* (UID FLAGS RFC822.SIZE BODY.PEEK[HEADER] INTERNALDATE)
when it really intended to send
    	5mwd UID FETCH 3229350339:* (UID FLAGS RFC822.SIZE BODY.PEEK[HEADER] INTERNALDATE)

Needless to say, the IMAP server objects to a negative number as a UID.

This problem exists in "Microsoft Internet Messaging API 6.00.2900.3028 
(xpsp_sp2_gdr.061107-0012)", or at least that's what it calls itself in 
the log.

This sounds like a great way for a site administrator to ban use of 
Outlook; just make the IMAP server assign UIDs starting at 0x80000000.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

