[Dovecot] Re: RFC 3501 compliance issue: It is a cache problem!

[Tony Kay]

I did some more work, and found a user who could reproduce the problem. I copied the folder to my account to try to debug it, and it worked fine. That led me to try copying his Dovecot cache files. Bingo: Problem.

I can send the index files, invalid fetch response, and folder...but not on a mailing list.

--
Anthony Kay
University Computing Center
(541) 346-1719
GPG Fingerprint: B0DB D46A 60AF FAE7 A94A  5075 0CB4 4D88 9F4F 7F09

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music.

    Donald E. Knuth 

On Mon, 15 May 2006 13:10:53 -0700, "Tony Kay" <tkay at uoregon.edu> wrote:
> Hi,
> 
> I am using Dovecot 1.0 beta 7, moving to beta8 probably tomorrow.
> 
> I am seeing a few RFC compliance issues with IMAP responses. I have an in-house IMAP client that caches IMAP data for a web mail system (it parses millions of IMAP interactions a day), and it reports whenever it gets a line that does not look RFC compliant. Unfortunately, users modify their mailboxes before I can get a copy that allows me to reproduce the errors. However, I can at least show you some examples of the response lines I'm seeing, since they are copied verbatim to my logs when they happen. 
> 
> I saw one case of imap-literal coming across without a \r\n sequence:
> 
> * 1135 FETCH (UID 1345 RFC822.SIZE 4813894 BODY (("text" "plain" ("charset" "ISO-8859-1") NIL NIL "7bit" 415 6)("application" "octet-stream" ("name" {59}C:\\Documents and Settings\\Mitch\\Desktop\\AIR JORDANS.ppt) NIL NIL "base64" 4811938) "mixed") BODY[1]<0> {80}
> We sorted out what technical difficulties we having and have posted a corrected  BODY[HEADER.FIELDS (FROM TO SUBJECT)] {90}
> From: XXX
> To: XXX
> Subject: Sports group II back online
> 
> )
> 
> This one is probably some weird malformed message, since literal strings processing is certainly not broken in general.
> 
> The much more common problem is when people receive a message that has a message embedded using the RFC3501 body-type-msg rule. Here is a sample incorrect response:
> 
> * 4154 FETCH (UID 27140 RFC822.SIZE 14078 BODY (("text" "plain" ("charset" "ISO-8859-1" "format" "flowed") NIL NIL "7bit" 2 1)("message" "rfc822" ("name" "casbudmgr: FW: deans-dirs: Scholarship Announcement") NIL NIL "7bit" 11694 ("Wed, 12 Apr 2006 14:42:04 -0700" "casbudmgr: FW: deans-dirs: Scholarship Announcement" (("xxxxxxx xxxx" NIL "xxxxxx" "xxx.xxxxxxx.xxx")) ((NIL NIL "xxxxxxxxxxxxxxx" "lists.xxxxxxxxxxx")) ((NIL NIL "casbudmgr" "xxxxx.xxxxxxx.xxx")) ((NIL NIL "xxxxxxxxx" "xxxxxxxxxxxxxxxxx")) NIL NIL NIL  <AF3B91355406B440A6E838338E63A742C6435B at xxxxxxxxxxxxxxxxxxxxxdu>") ("text" "plain" ("charset" "us-ascii") NIL NIL "quoted-printable" 2047 50)("text" "html" ("charset" "us-ascii") NIL NIL "quoted-printable" 6565 189) "alternative" 302)("text" "x-vcard" ("charset" "utf-8" "name" "ddkintz.vcf") NIL NIL "7bit" 415 14) "mixed"))
> 
> Look through the line to the point where you see: "alternative" 302.
> 
> The part the proceeds this is a body-type-mpart rule, but it is missing a set of parentheses...i.e. there should be an ending paren after alternative, and a beginning paren before the set of 1parts that precede it. 
> 
> This looks like a similar problem to what was in imap_bodystructure.c a while back.
> 
> --
> Anthony Kay
> University Computing Center
> (541) 346-1719
> GPG Fingerprint: B0DB D46A 60AF FAE7 A94A  5075 0CB4 4D88 9F4F 7F09
> 
> Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
>  
>     Rich Cook