Tony Kay
2006-May-15 20:10 UTC
[Dovecot] RFC 3501 compliance issue: body-type-msg incorrect
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
Tony Kay
2006-May-18 21:06 UTC
[Dovecot] Re: RFC 3501 compliance issue: It is a cache problem!
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
Timo Sirainen
2006-Jun-11 18:55 UTC
[Dovecot] RFC 3501 compliance issue: body-type-msg incorrect
On Mon, 2006-05-15 at 13:10 -0700, Tony Kay wrote:> * 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@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.This looks exactly like the problem I fixed 2006-02-18, and I can't reproduce it myself anymore. Does it still happen with you, even for new mails? I could take a look at the dovecot.index.cache file in that case. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://dovecot.org/pipermail/dovecot/attachments/20060611/05d32b9d/attachment.pgp