[Dovecot] can't read attachments using javamail with dovecot
Dear folks,
this might be a java-bug, but it seems to occur only when connecting to dovecot-IMAP.
UW and Cyrus-ditto works, while when I try to read attachments (base64), I get slapped in the face with this:
java.lang.NullPointerException at com.sun.mail.iap.Response.parse(Response.java:99) at com.sun.mail.iap.Response.<init>(Response.java:68) at com.sun.mail.imap.protocol.IMAPResponse.<init>(IMAPResponse.java:31) at com.sun.mail.imap.protocol.IMAPResponse.readResponse(IMAPResponse.java:105) at com.sun.mail.imap.protocol.IMAPProtocol.readResponse(IMAPProtocol.java:153) at com.sun.mail.iap.Protocol.command(Protocol.java:215) at com.sun.mail.imap.protocol.IMAPProtocol.fetch(IMAPProtocol.java:882) at com.sun.mail.imap.protocol.IMAPProtocol.fetch(IMAPProtocol.java:874) at com.sun.mail.imap.protocol.IMAPProtocol.fetchBody(IMAPProtocol.java:677) at com.sun.mail.imap.IMAPInputStream.fill(IMAPInputStream.java:74) at com.sun.mail.imap.IMAPInputStream.read(IMAPInputStream.java:105) at com.sun.mail.util.BASE64DecoderStream.decode(BASE64DecoderStream.java:143) at com.sun.mail.util.BASE64DecoderStream.read(BASE64DecoderStream.java:54) at se.illuminet.httpd.mail.MailXMLService.serviceXml(MailXMLService.java:361)
This occurs in booth javamail 1.2 and 1.3(.1) using dovecot. Of course this unfriendly/unhandled response is a problem with javamail while biting the dust.
Further analysis points to that the reading works OK up until 2^16 bytes, so it fails either in reading the tail of the attachment or resuming after the first buffered data is consumed.
I tried the BODYSTRCUTURE-patch (booth #1 and then #2), but it didn't help. Now I am fresh out of ideas. The java-bug has a three week delay to surface on "bug-parade". But I still have to explain why it works in UW/Cyrus and not with dovecot.
Next step would be to add trace-lines in dovecot.
Any ideas?
/Jonas
On Thu, 2003-09-25 at 12:23, Jonas Bosson wrote:
This occurs in booth javamail 1.2 and 1.3(.1) using dovecot. Of course this unfriendly/unhandled response is a problem with javamail while biting the dust.
Further analysis points to that the reading works OK up until 2^16 bytes, so it fails either in reading the tail of the attachment or resuming after the first buffered data is consumed.
Can you check what the IMAP traffic is between them? http://dovecot.procontrol.fi/bugreport.html#sniffing
It's probably asking the attachment in 64kB blocks and maybe Dovecot doesn't give a correct reply.. I think Mozilla works that way too and there hasn't been problems with it for a while now.
On Mon, 2003-09-29 at 15:54, Timo Sirainen wrote:
Can you check what the IMAP traffic is between them? http://dovecot.procontrol.fi/bugreport.html#sniffing
It's probably asking the attachment in 64kB blocks and maybe Dovecot doesn't give a correct reply.. I think Mozilla works that way too and there hasn't been problems with it for a while now.
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
best regards, Jonas
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
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
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
On Fri, 2003-10-03 at 16:33, Jonas Bosson wrote:
I have put the source mail and the traces from dovecot in: http://www.illuminet.se/test/error.tgz
Thanks. The real problem was the it was asking more data than there really was in the body part, and my checks were a bit wrong there.
participants (2)
-
Jonas Bosson
-
Timo Sirainen