Hmm, ok. (Won't argue with the man whose name is on the RFC. ^_^) May I suggest that, in future revisions of RFC 2060, that the paragraph in section 6.3.1, page 23:
If the client can not change the permanent state of one or more of the flags listed in the FLAGS untagged response, the server SHOULD send a PERMANENTFLAGS response code in an OK untagged response, listing the flags that the client can change permanently. be changed? In my opinion it suggests that the PERMANENTFLAGS response is optional if the client can change all of the FLAGS listed in the FLAGS untagged response. If it is the case that the server MUST send the PERMANENTFLAGS response if there are any flags that can be changed, then the PERMANENTFLAGS response code should be added to the list of untagged data items that MUST be sent. It seems exceptionally bogus that outlook would just not work on a system without IDLE. (After outlook does not get a response from my server, it pops up a dialog box saying "Hey user, your evil IMAP server timed out while I was trying to get new mail!" The is regardless of what I click.) I guess I should get started implementing IDLE.... john -----Original Message----- From: Mark Crispin [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Crispin Sent: Monday, February 10, 2003 10:26 AM To: John Doty Cc: Larry Osterman; [EMAIL PROTECTED] On Mon, 10 Feb 2003 10:12:45 -0800, John Doty wrote: > (Just so that I can believe I understand the RFC, PERMANENTFLAGS is > optional when it does not differ from the set of flags you returned > with the FLAGS status, right? It would gall me to have to include it > just because uw-imap > does...) PERMANENTFLAGS means that when you change the flag, the flag will stay changed in the next session, as distinguished from flags which are only valid in a particular session and are discarded when the session terminates. I think that what you are seeing is Outlook's standard behavior when the server does not support IDLE. Rather than periodically poll the server for new mail by issuing a command every few minutes (which is what it should do), it just sits there unless the user does a mouse click. FWIW, rumors to the contrary notwithstanding, NOOP is not a "poll command". All commands check for new mail on the selected stream as a side-effect. NOOP does nothing else, so if you want to poll for new mail but not do anything else, then you use NOOP. Anyway, the galling thing is that to work well with Outlook, you have to implement IDLE. But you're not done yet. Outlook won't terminate the idle state before the 30 minute inactivity autologout timer, even though the specification says that it should. So, at about 29 minutes into the IDLE, the server needs to send a hokey EXISTS announcing fake new mail, then when the client sends a DONE the server should send a hokey EXPUNGE to make the fake new mail go away. That will cause the client to issue a new idle and prevent the autologout.
