IMAP: multiple literal arguments not working?

[Torstein Tauno Svendsen <to...@visena.com>]

Hi! I tried using James (3.0.0-beta5-SNAPSHOT) behind a perdition proxy 
(http://horms.net/projects/perdition/), and noted that this makes IMAP 
login-requests hang.

Seems that when peridtion forwards the "LOGIN" request request it ends 
up sending something like:

A LOGIN {3}
foo {3}
bar

And this does not work with James - I see the expected "+" resonse after 
"LOGIN {3}", but there is no response to "foo {3}".

Sending only the password as a literal  - i.e.

"LOGIN foo {3}
bar"

works as expected .

Is this a bug in James or a misfeature in perdition? Sending all the 
arguments like literals works fine with dovecot.


-- 
Torstein Tauno Svendsen                torstein@visena.com
Seniorutvikler                              +47 932 95 901
Visena AS                           http://www.visena.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: IMAP: multiple literal arguments not working?

[Torstein Tauno Svendsen <to...@visena.com>]

On 09. okt. 2015 21:32, Torstein Tauno Svendsen wrote:
>
> Hi! I tried using James (3.0.0-beta5-SNAPSHOT) behind a perdition proxy
> (http://horms.net/projects/perdition/), and noted that this makes IMAP
> login-requests hang.
>
> Seems that when peridtion forwards the "LOGIN" request request it ends
> up sending something like:
>
> A LOGIN {3}
> foo {3}
> bar
>
> And this does not work with James - I see the expected "+" resonse after
> "LOGIN {3}", but there is no response to "foo {3}".
>
> Sending only the password as a literal  - i.e.
>
> "LOGIN foo {3}
> bar"
>
> works as expected .
>
> Is this a bug in James or a misfeature in perdition? Sending all the
> arguments like literals works fine with dovecot.

I tried digging into this - looks like there are two issues preventing 
this from working:

  1) AbstractNettyImapRequestLineReader uses a boolean ("retry") to 
determine if it should write continuation requests or not, so it can 
only support one literal argument

  2) ImapRequestFrameDecoder starts with "buffer.markReaderIndex()" and 
does a "buffer.resetReaderIndex()" to reset the reader index if it does 
not have enough data. But if a literal argument has been read, 
NettyImapRequestLineReader does this:

  InputStream in = new BoundedInputStream(new 
ChannelBufferInputStream(buffer), size);

And the ChannelBufferInputStream constructor ends up doing 
"buffer.markReaderIndex()", so the reader-index ImapRequestFrameDecoder 
should reset to has been overwritten.

Attaching a patch that seems to work for me.


-- 
Torstein Tauno Svendsen                torstein@visena.com
Seniorutvikler                              +47 932 95 901
Visena AS                           http://www.visena.com/