From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011214 BuildID: 20011214 According to RFC2060, the normal IMAP logout sequence (when initiated by the client) is this: 1. The client sends the LOGOUT command. 2. The server sends a BYE (untagged) response. 3. The server sends a OK (tagged) response. 4. The server closes its end of the connection. 5. The client closes its end of the connection. Mozilla doesn't obey this sequence. Instead, here's what Mozilla does: 1. Mozilla sends the LOGOUT command. 2. Mozilla closes its end of the connection and tears it down, without waiting for a response from the server. 3. The server sends a BYE (untagged) response. 4. The machine on which Mozilla is running sends a TCP RST to the server. 5. The server attempts to close its end of the connection. 6. The machine on which Mozilla is running sends another TCP RST to the server. This is clearly broken. Mozilla needs to conform to RFC2060. Also, as per section 7.1.5 of RFC2060, there are 3 separate cases where the server may send a BYE without any input from the client (due to a panic shutdown, due to an inactivity timer being reached, and as one of the three possible greetings at connection startup). I haven't [yet] tested how Mozilla handles these cases, but unless the IMAP code has already received lots of cleanups since Netscape 4.x, Mozilla will probably fail to do the right thing when the server initiates the BYE. This bug should be nominated for mozilla1.0.

Might I also add that if the IMAP server drops the connection Mozilla does not notice the fact at all. For example, open a folder on an IMAP server that has an inactivity timeout. When the timeout expires, if you try to read a message or do anything else Mozilla just hangs there with the throbber going and never notices that the connection has been dropped. To be able to read messages after that you must click Stop and then Get messages again. When the user requests an operation requiring communication with the server and the connection has been closed for some reason Mozilla should not fail silently and leave the throbber going forever but re-establish the connection, prompting the user for a password if necessary.

reporter, is this still the case in 0.9.9 or a recent nightly?

My comment #1 is no longer true in 2002032503 on Windows ME. I tested it by opening an imap folder on my imap server and then closing the connection by restarting the server. Mozilla does the right thing: it silently opens a new connection, without prompting me for a password, and generally behaves well. Smooth.

I think this problem has been fixed: I am unable to reproduce this bug on 2002032503 on Windows ME. This is what I see by sniffing the wire: (>> is Mozilla to server, << is server to Mozilla) >> 7 close << 7 OK mailbox closed. >> 8 logout << * BYE Courier-IMAP server shutting down << 8 OK LOGOUT completed This seems to be compliant with section 7.1.5, point 1 of RFC 2060.

i get similiar results as well ... what about you reporter?

Ok, I just evaluated yesterday's nightly build for RFC2060 conformance. Section 6.1.3 (LOGOUT command) conformance: Mozilla's logout handling is still broken, as I initially described. Specifically, Mozilla sends a tagged logout command, and then immediately closes its end of the TCP socket without finishing the logout sequence. All you need to do in order to reproduce this is to fire up Mozilla, login to an IMAP server, and then quit Mozilla. Now, as to the other closing behaviors... Section 7.1.5 condition #3 (BYE inactivity autologout) conformance: Mozilla handles inactivity logouts perfectly: if, after login, Mozilla receives an untagged BYE response, it notices immediately, and closes its end of the socket. Mozilla will then try to reconnect the next time the user does something that requires contacting the server. Provided the reconnect succeeds, the entire process is both silent and seamless; the user will have no idea the inactivity logout occurred. Great job guys! If the server *silently* closes the connection (without sending a BYE), Mozilla behaves as if the server prefixed the close with an untagged BYE command. This is probably the Right Thing to do: RFC2060 doesn't strictly require that a server sends an untagged BYE before closing a connection, so it shouldn't necessarily be treated as an error condition. Section 7.1.5 condition #4 (BYE connection greeting) conformance: If the server responds with an untagged BYE command when Mozilla first connects, Mozilla notices, and cooperates when the server then initiates the close. However, Mozilla doesn't see fit to notify the user in any way that the login failed. Mozilla will silently try to reconnect whenever the user does something to cause Mozilla to contact the server, but if the reconnect fails, whatever operation the user tried to perform (e.g. opening a mailbox) will silently fail. IMO, this is incorrect handling. If the server's greeting is an untagged BYE response, this is explicitly an error condition; it means the server is unwilling to accept connections from the client. This error should be reported to the user. The "human-readable text" portion of the BYE response should be included in the error message. E.g.: "Error: <server> is refusing logins: <human-readable text>"

Some expert should check that. NEW pi

*** Bug 93210 has been marked as a duplicate of this bug. ***

*** Bug 206862 has been marked as a duplicate of this bug. ***

Reassigning to Bienvenu, he has worked on the imap code lately. I believe this might cause at least UW-IMAPD to not expunge the open mailboxes when exiting. Instead an error "Command stream end of file, while reading line" is logged.

yes, we've never done this right. The reason has always been that we don't want to block the shutdown process if the imap server we're trying to log out of has gone away or is unreachable. We could try reading the response - it might be the case that the shutdown code will just kill our thread eventually anyway, but I don't know for sure. I might have to ping Darin for some ideas...

use Close() and Logout() commands, which will wait for the server to respond, if the server/connection is still alive. Also, needed to set IMAP_CONNECTION_IS_OPEN because we were never setting it!

fix checked in.

fixed on the m4 branch

I backed this out of the trunk (David and I had already backed it out of thunderbird 0.5) It seems to be triggering occassional deadlock when quitting the app, the app never exits. Sometimes it does exit, you just have to wait a little bit, but there are scenarios where it does not exit at all.

*** Bug 237412 has been marked as a duplicate of this bug. ***

(In reply to comment #15) The error "Command stream end of file, while reading line" server error seems to appear simultaneously with an end-user error in Thunderbird 0.5+ "The message was sent successfully, but could not be copied to your Sent folder. Would you like to return to the compose window?" Would the backed-out change or one like it case a better IMAP reset and avoid this problem?

The socket leaved opened when I close MozillaMail (but also when MozillaMail is still opened but is unused) cause that the account on the imap server is locked and CANNOT be accessed from another IMAP client like Eudora, ... All other client disconnect from the server when they do not need do UL/DL anything. To free the account I need to close the entire Mozilla. This is clearly a bad behaviour. Mozilla 1.7.2 Mozilla/5.0 (Windows; U; Windows NT 5.0; it-IT; rv:1.7.2) Gecko/20040803 on i686

The Mercury IMAP server has problem with this. When Mozilla or Thunderbid does not send "logout" (which I can see very often with the latest versions), the Mercury server did not save some values like subscribing or unsubscribing folders. I have posted it to the Mercury developers, but they do not consider it as the bug of the Mercury server. In the RFC3501 document is: > 3.4. Logout State > > ..... > A client SHOULD NOT unilaterally close the > connection, and instead SHOULD issue a LOGOUT command. If the > server detects that the client has unilaterally closed the > connection, the server MAY omit the untagged BYE response and > simply close its connection. So other reason for sending Logout every time.

I would like to confirm that Mozilla is still not handling a dropped connection from the server correctly. I use Mozilla on a laptop with a wireless card. When I pick up the laptop and move to a different access point that assigns it a new IP address without closing Mozilla, attempts to access previously opened IMAP folders hangs for some long period of time (~15 minutes). Attempts to use the existing connection to the server should in theory fail immediately at the TCP level, so I am not sure what Mozilla is waiting for.

(In reply to comment #20) Switch on logging of the IMAP connection. Set variables: set NSPR_LOG_FILE=imap.log set NSPR_LOG_MODULES=IMAP:5 start Mozilla and in the imap.log you will see messages of IMAP module. If you want only connection log, you can extract it from imap.log by simple Perl script: #!/usr/bin/perl -w while($radek = <>) { chomp($radek); if ($radek =~ /CreateNewLineFromSocket:(.*)$/) { print "<$1\n"; } if ($radek =~ /SendData:(.*)$/) { print ">$1\n"; } }

Confirm bad logout from IMAP server on Seamonkey 1.7.5 with Win2Ksp4

*** Bug 277751 has been marked as a duplicate of this bug. ***

fix as part of work in 60377