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.