dovecot - Sep 2003 - 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

Dear folks, this might be a javamail-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 it bites 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.