Mark, thank you for setting us straight on this. For me, another question arises: when a server detects a connection break, should it process any IMAP commands that it has pending for the session, or should it discard them? Seems to me that a good strategy would be to do so selectively. Obviously you don't want to process a SEARCH but it would be helpful to perform a CLOSE or LOGOUT.
At 07:44 AM 10/9/2002 -0700, Mark Crispin wrote: >If you do not send a LOGOUT and just close the connection: > >Depending upon how the operating system fields the event to the server, the >server will see it as a "Hangup" (SIGINT), "Terminated" (SIGTERM), or as "End >of file on stdin". In my experience, the last is the most common. > >If the server logs these events distinctly, the system manager of the server >system is going to see that this happened instead of a logout, and think that >something is wrong. > >It is a VERY frequent question "My server's syslog shows many `Command stream >end of file' messages. How do I fix this?" > >There are worse consequences. > >In some mailbox formats (most notably traditional UNIX format), flag settings >do not take immediate effect in the file, because it's an expensive operation >to update the file. Therefore, the new status is just noted in the server, >and the updates are cached for a later "checkpoint" or "expunge" operation. >LOGOUT does a checkpoint, as does SELECT/EXAMINE to a new mailbox. > >Now, of course the server will try to save the flag updates if the client >rudely hangs up on it. But it can't always do so. The server or the mailbox >may be in a state that precludes it. There are also cases in which an >[x]inetd server gets a SIGKILL instead of a SIGHUP. > >The result is that the flag changes are lost. > >The only excuse for a client not to send a proper LOGOUT is if the client >crashes. The LOGOUT command is in the protocol for a reason, and that reason >was not cosmetic. > >You should send a LOGOUT command, and wait for the response. If LOGOUT takes >a while, then it is doing something, such as saving user updates. You really >don't want to cause the server to get a SIGKILL while it is doing such.
