933416 - Protocol error causes POP using "STARTTLS, if available" to go into infinite protocol loop

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: POP, defect)

Description

[genpubsc]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 (Beta/Release)
Build ID: 20130916112225

Steps to reproduce:

I run SeaMonkey 2.21 on a Windows 7 machine to access multiple accounts.  Recently, on a POP account that uses "STARTTLS, if available" connection security and set up to check for new messages every 10 minutes, I noticed that mail was not being retrieved.  It would work fine for a while and then stop.  To get it to work again, I would go offline and then back online.  I was able to recreate this behavior by manually clicking the Get Msgs button repeatedly and eventually the mail retrieval for that account would appear to hang - the status line would be stuck saying "Connected to mailserver" where mailserver is the name of the server I was trying to connect to.

I tried all the usual things (disabling extensions, shutting down all other apps, etc.) and the behavior did not change.  I came to the conclusion that this was some sort of interaction between SeaMonkey and the particular server.  I ran wireshark to capture the output and sure enough, SeaMonkey and the Server get themselves into an infinite protocol loop.  It occurs right after SeaMonkey issues the CAPA command to the server.  What happens is that the Server (which may also have a bug) does not understand the CAPA command and responds with "-ERR Invalid command, try one of: USER name, PASS string, APOP name digest, QUIT".  SeaMonkey immediately responds with the STLS command (as if the server had responded normally to the CAPA command).  To this, the Server responds with the same "-ERR ..." message and SeaMonkey repeats the STLS command and the process repeats until the connection is actually severed (i.e. I go offline). 

At this point I don't know why the Server some times does not understand the CAPA command (I have an outstanding trouble ticket with the provider) but that is besides the point because SeaMonkey should recognize that the response to either the CAPA or the STLS command was not valid and either drop or restart the conversation. 

I expect that replication of this issue is going to be somewhat difficult because there may be aspects about my current setup and the Server's current setup that precipitate the behavior (and, for security reasons, I can not provide further client or server information).  On the other hand, it may be possible to see what the issue is just by inspecting the code.


Actual results:

The following is an example of an infinite conversation (after the initial setup of the pop port):

Server-> +OK POP3 server ready <server identifier>
SM-> CAPA
Server -> -ERR Invalid command, try one of: USER name, PASS string, APOP name digest, QUIT
SM -> STLS
Server -> -ERR Invalid command, try one of: USER name, PASS string, APOP name digest, QUIT
SM -> STLS
Server -> -ERR Invalid command, try one of: USER name, PASS string, APOP name digest, QUIT
SM -> STLS
etc.


Expected results:

The following is what happens when the CAPA is successfully received:

Server-> +OK POP3 server ready <server identifier>
SM-> CAPA
Server-> +OK Capability list follows
SM-> STLS
Server-> +OK Begin TLS Negotiation
SM-> Client Hello
Server-> Server Hello, Change Cipher Spec, Encrypted Handshake Message
etc.

Comment 1

[rsx11m]

Do you see the same with "STARTTLS" (thus, without the insecure fallback) or just with the setting described. Also, do you know which server (product/project name) you are connecting to?

Note that there is also bug 931034 on disrupted communication with STARTTLS.

Comment 2

[genpubsc]

Yes, I see the same with "STARTTLS".  The server is reporting Bigfoot V1.0.  I looked at 931034 before I reported this.  It did not look related to me because the protocol behavior was different and was concerned with STARTTLS over both IMAP and SMTP rather than POP.

Comment 3

[Wayne Mery (:wsmwk)]

Hi genpubsc.  Do you still see this problem?

Comment 4

[Phoenix]

Resolved per whiteboard