I believe that dovecot is doing something strange, when it founds a 'corrupted' multipart and using fetch body.
Look what I figured out:
- Sent a message from squirrelmail (it wrongly drop the last \n from epilogue):
------=_20090512171902_78105 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
n
------=_20090512171902_78105 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
n <--------(squirrelmail didn´t insert an additional \n). ------=_20090512171902_78105--
- Sent a correct message, inserting the last '\n':
------=_20090512171902_78105 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
n
------=_20090512171902_78105 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
n
------=_20090512171902_78105--
Compress both messages
Request the messages using: A004 UID FETCH 1 (FLAGS BODYSTRUCTURE) (the correct message):
127.000.000.001.00143-127.000.000.001.35604: * 1 FETCH (UID 1 FLAGS (\Seen) BODYSTRUCTURE (("text" "plain" ("charset" "iso-8859-1") NIL NIL "8bit" 7 3 NIL NIL NIL NIL)("text" "html" ("charset" "iso-8859-1") NIL NIL "8bit" *3 1*NIL NIL NIL NIL) "alternative" ("boundary" "----=_20090512171853_50085") NIL NIL NIL)) A004 OK Fetch completed. 5) Request the broken message:
127.000.000.001.00143-127.000.000.001.43679: * 2 FETCH (UID 2 FLAGS (\Seen) BODYSTRUCTURE (("text" "plain" ("charset" "iso-8859-1") NIL NIL "8bit" 7 3 NIL NIL NIL NIL)("text" "html" ("charset" "iso-8859-1") NIL NIL "8bit" *1 0*NIL NIL NIL NIL) "alternative" ("boundary" "----=_20090512171902_78105") NIL NIL NIL)) A004 OK Fetch completed.
From RFC the red numbers mean: size body, number of line for the body. This makes sense, because stripping the 'control' chars from first message, size and number of lines match. But in the second message, the line number is 0 - this does not make sense.
You need to test this using telnet, because outlook and thunderbird did not follow this way, they use body.peek.
What do you think? Fernando