RFC 2683 - IMAP4 Implementation Recommendations

"
Regarding inactivity timeouts, there is some controversy.  Unlike POP, for which the design is for a client to connect, retrieve mail,and log out, IMAP's design encourages long-lived (and mostly inactive) client/server sessions.  As the number of users grows, this can use up a lot of server resources, especially with clients that are designed to maintain sessions for mailboxes that the user has finished accessing.  To alleviate this, a server may implement an inactivity timeout, unilaterally closing a session (after first sending an untagged BYE, as noted above).  Some server operators have reported dramatic improvements in server performance after doing this. 
As specified in [RFC-2060], if such a timeout is done it must not be until at least 30 minutes of inactivity.  The reason for this specification is to prevent clients from sending commands (such as NOOP) to the server at frequent intervals simply to avert a too-early timeout.  If the client knows that the server may not time out the session for at least 30 minutes, then the client need not poll at intervals more frequent than, say, 25 minutes"

" The client/server connection may be severed for one of three reasons: the client severs the connection, the server severs the connection, or the connection is severed by outside forces beyond the control of the client and the server (a telephone line drops, for example).
Clients and servers must both deal with these situations. When the client wants to sever a connection, it's usually because it has finished the work it needed to do on that connection. The client should send a LOGOUT command, wait for the tagged response, and then close the socket. But note that, while this is what's intended in the protocol design, there isn't universal agreement here. Some contend that sending the LOGOUT and waiting for the two responses (untagged BYE and tagged OK) is wasteful and unnecessary, and that the client can simply close the socket. The server should interpret the closed socket as a log out by the client. The counterargument is that it's useful from the standpoint of cleanup, problem determination, and the like, to have an explicit client log out, because otherwise there is no way for the server to tell the difference between "closed socket because of log out" and "closed socket because communication was disrupted".
If there is a client/server interaction problem, a client which routinely terminates a session by breaking the connection without a LOGOUT will make it much more difficult to determine the problem. Because of this disagreement, server designers must be aware that some clients might close the socket without sending a LOGOUT. In any case, whether or not a LOGOUT was sent, the server should not implicitly expunge any messages from the selected mailbox. If a client wants the server to do so, it must send a CLOSE or EXPUNGE command explicitly.
When the server wants to sever a connection it's usually due to an inactivity timeout or is because a situation has arisen that has changed the state of the mail store in a way that the server can not communicate to the client. The server should send an untagged BYE response to the client and then close the socket. Sending an untagged BYE response before severing allows the server to send a human-readable explanation of the problem to the client, which the client may then log, display to the user, or both (see section 7.1.5 of [RFC-2060]). "

http://www.faqs.org/rfcs/rfc2683.html