[
https://issues.apache.org/jira/browse/IMAP-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640497#comment-13640497
]
Andrzej Rusin commented on IMAP-374:
------------------------------------
It looks like the original issue is invalid. Just to follow up, here is what I
found:
When using STARTTLS:
DEBUG 08:44:55,459 | james.imapserver | ID=-24390815 Got <tag>: 3mf1
DEBUG 08:44:55,459 | james.imapserver | ID=-24390815 Got <command>: NOOP
DEBUG 08:44:56,718 | james.imapserver | ID=-24390815 Error while processing
imap request
javax.net.ssl.SSLException: bad record MAC
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at
com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1429)
at
com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1397)
at
com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:932)
at
com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:837)
at
com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:713)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:607)
at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1118)
at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:814)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:422)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:311)
at
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:84)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:471)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:332)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
---------
on the client:
IMAP: 08:44:57 [tx] 3mf1 NOOP
IMAP: 08:44:58 [tx] s057 UID FETCH 16301.............3352087:3352170 (UID FLAGS
RFC822.SIZE BODY.PEEK[HEADER])
IMAP: 08:44:58 [tx] r3uh NOOP
IMAP: 08:44:58 [db] OnNotify: asOld = 5, asNew = 5, ae = 3
IMAP: 08:44:58 [rx] 3mf1 OK NOOP completed.
IMAP: 08:44:58 [db] Connection to 'xxxxxxxxxxxxx' closed.
IMAP: 08:44:58 [db] OnNotify: asOld = 5, asNew = 0, ae = 5
IMAP: 08:44:58 [db] ERROR: "Your server unexpectedly terminated the connection.
Possible causes include server problems, network problems, or a long period of
inactivity.", hr=2148322319
When using SSL on port 993 with stunnel (to rule out any possible Java SSL
issue) there is very similar behaviour, just different exception:
DEBUG 10:15:01,847 | james.imapserver | ID=-2010009041 Got <tag>: q6m5
DEBUG 10:15:01,847 | james.imapserver | ID=-2010009041 Got <command>: IDLE
DEBUG 10:15:02,292 | james.imapserver | ID=-2010009041 Error while processing
imap request
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:202)
at sun.nio.ch.IOUtil.read(IOUtil.java:169)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:243)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:59)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:471)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:332)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
----------
and on the client
IMAP: 10:15:03 [tx] q6m5 IDLE
IMAP: 10:15:03 [db] OnNotify: asOld = 5, asNew = 5, ae = 3
IMAP: 10:15:03 [rx] + Idling
IMAP: 10:15:04 [tx] DONE
IMAP: 10:15:04 [db] OnNotify: asOld = 5, asNew = 5, ae = 3
IMAP: 10:15:04 [rx] q6m5 OK IDLE completed.
IMAP: 10:15:04 [tx] io3r UID FETCH 16301...3352087:3352170 (UID FLAGS
RFC822.SIZE BODY.PEEK[HEADER])
IMAP: 08:44:58 [tx] r3uh NOOP
IMAP: 08:44:58 [db] OnNotify: asOld = 5, asNew = 5, ae = 3
IMAP: 08:44:58 [rx] 3mf1 OK NOOP completed.
IMAP: 08:44:58 [db] Connection to 'xxxxxxxxxxxxxx' closed.
IMAP: 08:44:58 [db] OnNotify: asOld = 5, asNew = 0, ae = 5
IMAP: 08:44:58 [db] ERROR: "Your server unexpectedly terminated the connection.
Possible causes include server problems, network problems, or a long period of
inactivity.", hr=2148322319
What I think is that the clients sends invalid SSL stream, which breaks both
the Java SSL in STARTTLS mode and stunnel SSL in full SSL mode.
The last command successfully received by IMAP is the one before the giant UID
FETCH. This can be seen in the command tags in both logs.
> Client command line length limit is problematic
> -----------------------------------------------
>
> Key: IMAP-374
> URL: https://issues.apache.org/jira/browse/IMAP-374
> Project: James Imap
> Issue Type: Bug
> Components: Protocol
> Reporter: Andrzej Rusin
> Assignee: Eric Charles
>
> I believe (based on some observations) that:
> A) maximum client command line length in James IMAP is 8192 as defined in
> org.apache.james.protocols.netty.AbstractChannelPipelineFactory.MAX_LINE_LENGTH.
> B) I do not think that IMAP RFC limits the line length, at least I did not
> find any reference of that.
> C) James IMAP does not seem to reply with BAD when it sees a too long line.
> D) Some clients send quite long lines (I just saw one about 23000 characters
> and sky is the limit) and they probably expect some answer, hanging
> indefinitely.
> So:
> 1. If B is true, then we should not practically really limit in A; or rather
> the limit should be really high. And looks like 640K is not enough for
> everyone anymore ;)
> 2. Probably C should be fixed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
