I am wondering if anyone can point me in the right direction in fixing this issue, as I have several thousand users experiencing this problem.

And I am really not looking forward to backing out and going back to wu-imap.

If someone could shed some light on this it would really be appreciated.

Ryan Hulsker

On Fri, 2004-10-01 at 14:33, Ryan Hulsker wrote:

Ok, I have narrowed my IMP/Dovecot attachment problem down to what I think is a bug in Dovecot. The test that follow are performed on 0.99.11.

When you download an attachment in IMP it uses the php function imap_fetchbody() which contacts the IMAP server and retrieves just the mime chunk you are looking for.

It does this by first fetching some information about the email, and then grabs the specific chunk you are looking for in a second request.

The first request looks like this.

"FETCH 258 (ENVELOPE BODY.PEEK[HEADER.FIELDS (Path Message-ID Newsgroups Followup-To References)] BODYSTRUCTURE INTERNALDATE RFC822.SIZE FLAGS)"

Dovecot responds properly on all parts of this request except for the BODYSTRUCTURE portion which gets returned as this.

"BODYSTRUCTURE ("text" "plain" NIL NIL NIL "7bit" 0 0 NIL NIL NIL)"

This causes the imap_fetchbody() funtion to freak out and not do the 2nd request, and it returns 0 bytes.

If I manually try "FETCH 258 (BODYSTRUCTURE)" Dovecot returns the expected data properly.

I figured there must be an interaction between the BODYSTRUCTURE fetch and one of the other items that are requested, so I tried them all and narrowed it down to this.

FETCH 258 (BODYSTRUCTURE) <- works OK

FETCH 258 (BODYSTRUCTURE RFC822.SIZE) <- BODYSTRUCTURE reply is wrong.

I have been surfing through the dovecot source looking for a way to fix or work around this, but I am only a mediocre C coder.

Can anyone enlighten me?

Ryan Hulsker