Thank I found the issue. For certain instances our Message.getBodyContent or getFullContent may return a FileInputStream.
In ChannelImapResponseWriter.write if the InputStream of the passed in Literal is instanceof FileInputStream a ChunkedNioFile gets used instead of DefaultFileRegion or ChunkedStream. As a quick test I wrapped my FileInputStream with a BufferedInputStream and now everything works. I still have no idea why a ChunkedNioFile fails but I imagine that not many Mailbox implementations are returning FileInputStream and thus no one else is really seeing this issue. Regards, Roy On Wed, Dec 2, 2015 at 5:07 PM, Roy Rim <[email protected]> wrote: Hey guys, So I've been looking at the James source code and I still can't figure out what we are doing wrong. If I'm understanding the code correctly outside of the Netty ChannelPipeline having the SslHanndler added to it there are literally no differences in how IMAP commands get handled. This command should work the same with and without SSL right? 4 UID FETCH 1 (BODY.PEEK[TEXT]) However what I'm seeing is that without SSL the BODY.PEEK[TEXT] works fine and ends with: [body content]) 4 OK FETCH COMPLETED And with SSL all I get is the body, but it doesn't finish the fetch response: [body content] And no ending parenthesis and it just hangs when I use openssl. Running wireshark I do see that the server is still continually returning something and will continue until I close the connection. Which I suspect means I've got some weird encoding issue. Perhaps my file (that is basically rfc822) needs to guarantee to be in some charset or encoding? If anyone has a better understanding of how SSL is handled I would greatly appreciate any advice. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
