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.