Greetings
I've attached a patch that fixes a bug in Dovecot relating to rfc822
attachments. This problem shows up in Mulberry (which hammers the IMAP
protocol more than most!).
The problem is that FETCH BODY[n], where "n" is the number for the
message/rfc822 part, returns the wrong information. It returns the message
without the headers, whereas it should return the entire rfc822 attachment.
FETCH BODY[n.MIME] doesn't appear to return the MIME headers for the part
either.
This happens because the find_part() function always steps down into the
child when the type of the part is RFC822. It should only do this if the
request is for a sub-part, or for HEADER. Otherwise it should stay at the
current level.
I have to say the IMAP protocol is a bit perverse in the way implicit
nesting of rfc822 messages is handled, which is why this looks somewhat
hacky. I don't see a nicer way though.
The effect in Mulberry is that certain operations on rfc822 attachments
don't work properly, in particular extracting the attachment into a
separate message. It also affects message-digest format messages, which
will completely lock up Mulberry if one is even present in a mailbox. (It
may be that Dovecot itself hangs, I don't know. Once I found that the patch
fixed both problems I didn't look any further :) Mulberry doesn't
exhibit
these problems with other IMAP servers.
The attached patch is for the source code of 0.99.10.04. I've looked at the
"latest" source, and there is no change in these lines of code, so I
guess
the bug is still there.
--
Best regards
Rick Jones
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imap-fetch-body-section.patch
Type: application/octet-stream
Size: 527 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20040403/da14cda9/attachment-0001.obj>
