IMAP Gateway: severed connections
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenMapi.org |
New
|
Undecided
|
Unassigned |
Bug Description
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.