(resending) bug in ngx_mail_proxy_read_response

Mansoor Peerbhoy mansoor at zimbra.com
Sun Nov 11 14:22:36 MSK 2007


Hello Igor, please ignore my earlier e-mail since it was incomplete:

We have come across a small bug in the function ngx_mail_proxy_read_response() in src/mail/ngx_mail_proxy_module.c:
Basically, after sending the LOGIN command (along with the password) to the upstream server, NGINX immediately expects the tagged response (OK/NO) from the upstream server.

However, according to the IMAP RFC 3501, section 6.2.3:

      A server MAY include a CAPABILITY response code in the tagged OK
      response to a successful LOGIN command in order to send
      capabilities automatically.  It is unnecessary for a client to
      send a separate CAPABILITY command if it recognizes these
      automatic capabilities.

This breaks nginx because it is searching for the tagged response in the switch case inside the ngx_mail_proxy_read_response() function (case ngx_imap_passwd).

This causes the following error to appear in nginx logs, because the code is not able to handle the untagged response:

2007/11/11 16:03:40 [info] 3917#0: *3 upstream sent invalid response: "* CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ESEARCH ID IDLE LIST-EXTENDED LITERAL+ LOGIN-REFERRALS MULTIAPPEND NAMESPACE QUOTA RIGHTS=ektx SASL-IR UIDPLUS UNSELECT WITHIN X-DRAFT-I05-SEARCHRES
1 OK LOGIN completed" while reading response from upstream, client: 127.0.0.1, server: 0.0.0.0:1143, login: "user1 at mansoor-dev.in.zimbra.com", upstream: 127.0.0.1:7143

There is also another issue. During integration of nginx proxy with our Zimbra IMAP mail server, we have noticed the following: If the server side does a flush between sending the untagged capability response and the tagged result to the LOGIN command, as follows:

There is also another issue. During integration of nginx proxy with our Zimbra IMAP mail server, we have noticed the following: If the server side does a flush between sending the untagged capability response and the tagged result to the LOGIN command, as follows:

* OK localhost Zimbra IMAP4rev1 service ready
1 login mansoor secret
* CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ESEARCH ID IDLE LIST-EXTENDED LITERAL+ LOGIN-REFERRALS MULTIAPPEND NAMESPACE QUOTA RIGHTS=ektx SASL-IR UIDPLUS UNSELECT WITHIN X-DRAFT-I05-SEARCHRES
// ----- upstream server flushes socket -----
1 OK LOGIN completed


In this case, the recv() function call at the start of the ngx_mail_proxy_read_response function does not receive both the lines in one call (we require to make a second call to recv() to fetch the tagged response).

The attached patch fixes both issues, I have commented the code as necessary.

Please consider including the patch into nginx (I tested the bug, and the patch on nginx-0.5.33).


Regards,

Md. Mansoor Peerbhoy
http://www.zimbra.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: login-untagged-response.patch
Type: application/octet-stream
Size: 2509 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx/attachments/20071111/b395d010/attachment.obj>


More information about the nginx mailing list