321599 - IMAP hangs on UID fetch failure in a folder [Syntax error on untagged response violating IMAP protocol]

Status: VERIFIED INVALID

(MailNews Core :: Networking: IMAP, defect)

Description

[t3rmin4t0r]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 CentOS/1.0.7-1.4.1.centos4 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 CentOS/1.0.7-1.4.1.centos4 Firefox/1.0.7

The IMAP server response parser kills the thread with a syntax error when it encounters an error on a particular message, ignoring further data from server. The IMAP client logs out and socket is closed - without any error to the user.

The imap:5 log says 

112905136[b6562480]: b6559af8:us.f318.mail.yahoo.com:S-foss.in:PARSER:
  Internal Syntax Error: %s: * 1072 NO  message error; can't fetch that message
112905136[b6562480]: b6559af8:us.f318.mail.yahoo.com:S-foss.in:SendData:TellThreadToDie: 8 logout
112905136[b6562480]: b6559af8:us.f318.mail.yahoo.com:S-foss.in:TellThreadToDie: close socket connection

The tcp traffic indicates the following 

  4 UID fetch 34095:34357 (UID RFC822.SIZE.....)
  * 1072 NO  message error; can't fetch that message

  5 logout
  * 1073 FETCH (FLAGS (\Seen) RFC822.SIZE 7658 ...)
  X-Apparently-To: [e-mail] via 68.142.207.xx; 
                 Fri, 16 Dec 2005 21:52:01 -0800

The expected result is for the induvidual message errors to be ignored
as the end result of the UID fetch will be as follows

  4 UID fetch 34620 (UID RFC822.SIZE FLAGS ....)])
  * 553 NO  message error; can't fetch that message
  4 NO UID FETCH error; can't fetch that data



Reproducible: Always

Steps to Reproduce:
1. Access folder with corrupt IMAP index

Actual Results:  
Thunderbird hangs

Expected Results:  
Download all other available messages and complain about the error.

Quick fix:

Index: nsImapServerResponseParser.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp,v
retrieving revision 1.122.8.2
diff -u -r1.122.8.2 nsImapServerResponseParser.cpp
--- nsImapServerResponseParser.cpp	22 Sep 2005 23:29:11 -0000	1.122.8.2
+++ nsImapServerResponseParser.cpp	23 Dec 2005 02:29:24 -0000
@@ -1027,6 +1027,11 @@
         fFlagState->ExpungeByIndex((PRUint32) tokenNumber);
       skip_to_CRLF();
     }
+    else if(!PL_strcasecmp(fNextToken, "NO"))
+    {
+       /* crude !! */
+       skip_to_CRLF();
+    }
     else
       msg_obsolete();
   }

Comment 1

[t3rmin4t0r]

Please visit http://t3.dotgnu.info/blog/tags/mozilla/

For a complete gdb stack trace of the problem (in case).

Also find the IMAP trace log at http://t3.dotgnu.info/code/imap-log.log.gz

Comment 2

[Vidar Haarr (not reading bugmail)]

Attachment: patch from comment 0 as attachment

Please use the attachment and review flag features.

bienvenu: This is the same patch as pasted in comment 0, from the reporter. The patch is against the 1.7 branch but should apply cleanly with some fuzz.

Comment 3

[Vidar Haarr (not reading bugmail)]

I'm not confirming this bug since I don't have time to triage it.

Comment 4

[Hans-Andreas Engel]

According to RFC3501, an untagged response has the following form.
    response-data   = "*" SP (resp-cond-state / resp-cond-bye /
                      mailbox-data / message-data / capability-data) CRLF

    resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
                        ; Status condition

    message-data    = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))


However, note that the server responded 
     * 1072 NO  message error; can't fetch that message
which included a number before the "NO" response.  The proper response would have been
    * NO message error; can't fetch that message
Thus, the server violated the IMAP protocol and the current behavior of thunderbird/mozilla, flagging a syntax error, is technically correct (and the patch 206925 is incorrect).

So this is an intriguing bug indeed, but it turns out that it is the server's fault, suggesting to mark this bug as INVALID.  (On the other hand, proper handling of untagged NO responses in not yet implemented in thunderbird/mozilla.)

t3rmin4t0r, what kind and what version of IMAP server are you using?

Comment 5

[Hans-Andreas Engel]

Note that according to RFC3501, Sec. 7.1, "the untagged [NO response] indicates a  warning; the command can still complete successfully."  

Thunderbird/mozilla ignores such untagged NO responses, see
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp&rev=1.133&root=/cvsroot&mark=1719-1723#1713
Thus, NO responses are properly handled.

Comment 6

[David :Bienvenu]

I'm inclined to agree with Hans-Andreas - this is the server's fault in several ways and I wouldn't want to break anything by trying to handle this invalid response...

Comment 7

[David :Bienvenu]

Comment on attachment 206925 [details] [diff] [review]
patch from comment 0 as attachment

minusing...