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.
