Closed Bug 115349 Opened 23 years ago Closed 19 years ago

Mozilla doesn't properly handle IMAP logout / connection closes (RFC2060)

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ralston, Assigned: Bienvenu)

References

Details

Attachments

(1 file)

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: huang → gchan
Summary: Mozilla doesn't properly handle IMAP logout / connection closes → Mozilla doesn't properly handle IMAP logout / connection closes (RFC2060)
*** 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. 
Assignee: mscott → bienvenu
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...
Status: NEW → ASSIGNED
Attached patch proposed fixSplinter Review
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!
Attachment #139929 - Flags: superreview?(mscott)
Attachment #139929 - Flags: superreview?(mscott) → superreview+
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
fixed on the m4 branch
Blocks: 230700
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.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** 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";
	}
}
Product: MailNews → Core
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
Status: REOPENED → RESOLVED
Closed: 21 years ago19 years ago
Resolution: --- → FIXED
Product: Core → MailNews Core
See Also: → 60377
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: