[Dovecot] Clients hang because imap-login discards post-login commands

[Mike Abbott]

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.