dovecot - May 2008 - Clients hang because imap-login discards post-login commands

Some of my IMAP clients hang when connecting to Dovecot 1.1.rc5.  I  
believe the problem is that imap-login reads eagerly rather than  
sparingly.  If a client sends
a login user password
b select Inbox
all at once, without waiting for the login reply before sending the  
select, imap-login eats the second command (reads it from the socket  
and does nothing with it; system call tracing confirms this) and the  
client hangs waiting for a reply to the select command.  I can  
reproduce this simply using telnet to the dovecot on localhost, as  
long as I send both lines at once (I paste them in together).

$ telnet localhost 143
* OK Dovecot ready.
a login user password
b select Inbox
a OK Logged in.
<dovecot never replies to select>

This may also be true with pop3-login, I have not checked.  It does  
happen (with IMAP) when authentication is delayed and Dovecot responds  
with "* OK Waiting for authentication process to respond.." but I  
believe that shares the same underlying cause as the simpler case above.

I believe the login processes should read only as much as they need to  
satisfy the login request and leave subsequent commands in the socket  
for post-login processing.  Or, the login processes should pass the  
remainder of their input buffers to the mail processes so no commands  
are dropped.  This section of RFC 2060 explains why I think this:

5.5.    Multiple Commands in Progress

    The client MAY send another command without waiting for the
    completion result response of a command, subject to ambiguity rules
    (see below) and flow control constraints on the underlying data
    stream.  Similarly, a server MAY begin processing another command
    before processing the current command to completion, subject to
    ambiguity rules.  [...]

    The exception is if an ambiguity would result because of a command
    that would affect the results of other commands.  Clients MUST NOT
    send multiple commands without waiting if an ambiguity would result.
    If the server detects a possible ambiguity, it MUST execute commands
    to completion in the order given by the client.

So it appears that both the client and Dovecot may be in violation,  
depending on how you define "ambiguity."  The RFC does not explicitly
define whether login causes an ambiguity, but I personally believe  
that login does "affect the results of other commands" (the login may
fail, for instance).  So the client should not issue commands before  
receiving the login reply, and Dovecot should not drop commands during  
login.  I have reported the client issue to the developers of the IMAP  
client, as I am reporting the server issue to you.  Fortunately for  
me, only one or the other needs to change to erase the symptom (hung  
clients), but fixing both would be best.

Thanks for your attention.

Mike Abbott wrote:
> So it appears that both the client and Dovecot may be in violation, 
> depending on how you define "ambiguity."  The RFC does not
explicitly
> define whether login causes an ambiguity, but I personally believe that 
> login does "affect the results of other commands" (the login may
fail,
> for instance).  So the client should not issue commands before receiving 
> the login reply, and Dovecot should not drop commands during login.  I 
> have reported the client issue to the developers of the IMAP client, as 
> I am reporting the server issue to you.  Fortunately for me, only one or 
> the other needs to change to erase the symptom (hung clients), but 
> fixing both would be best.
See, I can't see how user authentication can NOT effect the results of other
commands - if you fail to authenticate, almost EVERY subsequent command 
result would change.

Whilst I agree it would be nice for dovecot's auth task to pass on the extra
comms buffers, it sounds VERY broken to me for the client to be issuing 
commands blindly without waiting to ensure login worked.

Can I ask which IMAP client has this 'quirky' behavior, that I may avoid
it
in future?

-- 
Curtis Maloney
cmaloney at cardgate.net

On May 21, 2008, at 11:41 PM, Mike Abbott wrote:
> Some of my IMAP clients hang when connecting to Dovecot 1.1.rc5.  I  
> believe the problem is that imap-login reads eagerly rather than  
> sparingly.  If a client sends
> a login user password
> b select Inbox
> all at once, without waiting for the login reply before sending the  
> select, imap-login eats the second command (reads it from the socket  
> and does nothing with it; system call tracing confirms this) and the  
> client hangs waiting for a reply to the select command.  I can  
> reproduce this simply using telnet to the dovecot on localhost, as  
> long as I send both lines at once (I paste them in together).
I've known about this for several years, but since the fix isn't too  
simple and I haven't before heard of any clients actually doing this,  
I haven't bothered to fix it yet. I think Courier-IMAP has/had also  
the same problem. What client is this with?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080522/07402ae6/attachment-0002.bin>