I have put the source mail and the traces from dovecot in: http://www.illuminet.se/test/error.tgz
It also seems there is different behavior in size, small sizes work fine, but larger attachments go bezerk. This example for instance overruns the boundary of the larger attachment and displays part of the following one.
I have been tracing the use of message_find_boundary and message_size structs, but have not found the miss calculation yet.
/Jonas
On Thu, 2003-10-02 at 18:22, Jonas Bosson wrote:
Where should I look to change this behavior (below)? lib-mail, lib-imap or lib-storage?
On Mon, 2003-09-29 at 19:42, Jonas Bosson wrote:
On Mon, 2003-09-29 at 19:02, Jonas Bosson wrote:
Now I have conducted the trace and all seems fine, unless dovecot should not append the mime-boundary too... witch it does. That could explain why the javamail base64 parser flips out.
It this the problem perhaps?
--- snip from tail --- zym/MizHsizPMi3Xsi3f8qgFBAAAOx==
--=-u5ZQZIAhsi8nf+mzzgM1-- ) A9 OK Fetch completed. --- SNAP
Also, dovecot includes the boundary in the "length" of the body part in:
A3 OK [READ-ONLY] Select completed.
- 103 FETCH (BODYSTRUCTURE (("text" "plain" ("charset" "us-ascii") NIL NIL "7bit" 15 3 NIL NIL NIL)("image" "gif" ("name" "usenet-traffic-globe.gif") NIL NIL "base64" 81076 NIL ("attachment" ("filename" "usenet-traffic-globe.gif")) NIL) "mixed" ("boundary" "=-u5ZQZIAhsi8nf+mzzgM1") NIL NIL)) A4 OK Fetch completed.
81076 includes the boundary shown above. Sorry if this is entirely up the wrong tree. And thanks for any advice.
/Jonas