IMAP Gateway: severed connections

see, if there needs to be any change, to fulfill the required handling of severed connecitons:

3.1.2. Severed Connections

   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]).

   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.