Kris Kelley wrote: >> Our email servers run Courier IMAP 1.5.1 Today, a user showed me an >> error message Outlook gave him, stating, "Your server has reported a >> UID which does not comply with the IMAP standard. This typically >> indicates a server bug. Your program may not function properly >> after this." The dialog box then shows this info: >> >> MsgSeqNum 12891, New UID 49023, Prev UID: 49023, Next UID: 0.
Sam Varshavshik wrote: > This must be some stupid MSOE bug. No matter how the server juggles > UIDs, Courier-IMAP will NEVER report "Next UID: 0". MSOE definitely > pulled that one out of its ass. I figured the "Next UID: 0" message was bunk. I was more concerned about the current message apparently having the same UID as the previous message. In fact, another user reported the problem today, and he saw this: MsgSeqNum 734, New UID 36747. Prev UID: 36741, Next UID: 36746. > The only process that ever updates the UID file is Courier-IMAP. The > UID file is not updated by anything that delivers mail. Furthermore, > the only situations where two different Courier-IMAP servers would > fight over the same UID file would be if the same poorly-written IMAP > client somehow felt the need to log in two or more times, open the > same folder in each login session, and request the server to check > for new mail on both sessions, at the same time. Yep, that's Outlook. I've already encountered other problems caused by multiple connections to the same folder. > MSOE's assumption that it can log in multiple times to the same > folder, and receive the same UID/UIDvs for the same message is wrong. > A server is well within its rights to generate a completely new UID > set for each new log in (and, in fact, Courier-IMAP will do precisely > that in certain rare pathological situations where filesystem hard > quotas prevent it from saving the UID file itself). No hard quotas here, but I see your point. Even if the UID set is not generated from scratch for each session, if multiple sessions see new email, they may step on each others' assignments of UIDs for those new messages. Am I understanding that correctly? Just to be thorough: Due to a different problem, we had some message files generated between 25 October and 28 October end up with incorrect timestamps. This resulted in the INTERNALDATE for these messages being incorrect, even though the message headers had correct timestamps in all the relevant places. Could that have somehow aggravated this UID problem? I'm ready to file this one under MS stupidity, but I want to make sure there aren't any other influences I have control over that might be factors. ---Kris Kelley ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
