[
https://issues.apache.org/jira/browse/IMAP-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641563#comment-13641563
]
Andrzej Rusin commented on IMAP-374:
------------------------------------
Yes, it's MS Outlook 2007.
Just guessing: I can think of one possible issue in James:
As seen in the logs (if they properly show the flow of events), the client
pipelines the requests without waiting for answers:
s057 UID FETCH and r3uh NOOP is issued before the answer to 3mf1 NOOP which
comes later than s057 UID FETCH
Any way to check if it can cause any problems in James?
> Strange problem with a huge request from client
> -----------------------------------------------
>
> 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]
