Coffeehouse Thread

8 posts

Outlook 2002

Back to Forum: Coffeehouse
  • User profile image
    JAnderson

    I use Outlook 2002 with several email accounts.  I have set the accounts to use IMAP.

    Can anything be done about the message that appears indicating that the IMAP server has closed the connection due to a timeout?  The message appears several times a day and can be quite annoying.

    Thanks!

  • User profile image
    JohnSands

    Off-topic, I know, but Mozilla Thunderbird is an excellent IMAP client.

  • User profile image
    vanlandw

    i use thunderbird with a plugin called thundertray and it's great..i'm not a big e-mail guy but it makes it easy and it's free and ad free....very nice

  • User profile image
    Bowski

    I have heard about this happening before, but we haven't been able to completely track it down.

    If you would like to help, you can enable logging and send us the log file.  This is explained in the following KB article.

    http://support.microsoft.com/default.aspx?scid=kb;en-us;300479 

    Feel free to send the logs to outwish@microsoft.com.

  • User profile image
    spod

    this may not work, and usual "touch the registry at your own risk" warnings apply...

    you could try setting the following registry keys to a larger number.

    browse to...
    HKEY_CURRENT_USER\software\Microsoft\Internet Account Manager\Accounts 

    The settings will be within the separate account folders. For example:
       HKEY_CURRENT_USER\software\Microsoft\Internet Account
       Manager\Accounts\00000006 The keys for the server timeout settings are:
       "IMAP Timeout"=dword:0000012c "SMTP Timeout"=dword:0000012c

    values are in hex in seconds...

    cheers
    jeff

  • User profile image
    JAnderson

    I have enabled logging.  Do logs get created everytime the server is checked for mail?  I am thinkng yes.

    Would I need to send all of those logs? Or just the logs with the "Your IMAP server has closed the connection." message?

  • User profile image
    prog_dotnet

    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

  • User profile image
    JAnderson

    Think I have the problem solved, for today anyway..so far.

    I found a setting on my mail server

    "IMAP NOOP and IDLE commands trigger 1 minute inactivity timeout"

    I disabled that option and also increased the IMAP sessions timeout, it was 20min.

    I am thinking of setting the minutes back to the 20 since I am feeling that the above described option was the actual problem.

    Thanks to all who posted!

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.