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.

Reply via email to