Quick fix for a bug caused by a client sending the highestmodseq IMAP command when IMAPSession->mailbox is null, causing a crash
Possible fix for the CLOSE_WAIT problem. Always call session_bailout when in CLIENT_EOF state
Fixed a problem caused by attempting to write to a socket faster than the kernel can handle? This may be a bit of a hack
If an IMAP connect enters the CLIENT_ERR state, we won't close() the connection unless we're current in CLIENTSTATE_QUIT_QUEUED
Forcibly close IMAP sessions if they are left open with a non-empty write buffer

If an IMAP session times out while it still has pending data to be sent, the IMAP server might end up in a infinite loop caused by continously scheduling imap_cleanup_deferred.
This will cause a accidental denial-of-service because no new events will be processed while in this loop.

If we're already in imap_cleanup_deferred, we can assume that this connection *should* be closed promptly and there isn't any point in actually ensuring the data is sent properly.
We will now attempt to send the data once, but if we fail then we will close the connection anyway.