imap connection to gmail closes connection
mdounin at mdounin.ru
Wed Jan 15 18:00:50 UTC 2014
On Wed, Jan 15, 2014 at 11:28:18AM -0600, ktm at rice.edu wrote:
> On Wed, Jan 15, 2014 at 08:51:57PM +0400, Maxim Dounin wrote:
> > Hello!
> > On Wed, Jan 15, 2014 at 10:37:29AM -0500, bidwell wrote:
> > > I am running nginx 1.1.19 on an Ubuntu 12.04.4 64but server.
> > >
> > > I have nginx configured to enter on port 143 and go out to 127.0.0.1:143
> > > where it goes through stunnel to go to imap.gmail.com:993. If I talk
> > > directly to 127.0.0.1:143 (to stunnel) it works. If I talk to nginx, it
> > > authenticates, logs correct username, target IP and port, gets the
> > > Capability list and registers a successful login to the remote (gmail) imap
> > > server and then closes the connection immediately. The following is a
> > > transcript of the telnet session:
> > >
> > > telnet nginx:143
> > > * OK IMAP4 ready
> > > a1 LOGIN user at example.com password
> > > * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN
> > > X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH
> > > a1 OK user at example.com first_name Last_name authenticated (Success)
> > > Connection closed by foreign host.
> > >
> > > My nginx error.log shows the following:
> > > *5 upstream sent invalid response: "* CAPABILITY IMAP4rev1 UNSELECT IDLE
> > > NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE
> > > MOVE CONDSTORE ESEARCH
> > > a1 OK test at example.com Test User authenticated (Success)" while reading
> > > response from upstream,...
> > >
> > > It appears to not like google's CAPABILITY line. Is it too long? Any
> > > suggestions?
> > >
> > > Other connections through nginx/stunnel to exchange work just fine.
> > The problem is that nginx doesn't expect multiple responses to the
> > LOGIN command.
> > --
> > Maxim Dounin
> > http://nginx.org/
> Hi Maxim,
> I tried posting to the list but it never came through.
You have to be subscribed to the list to post to it, see
> Here is the patch
> we found in the nginx archives to address this problem.
Thanks, it looks like the patch from this message:
Posting the link on the list in case it will be usable for
Unfortunately, the patch is more like a quick-and-dirty
workaround, and needs more work before it can be committed.
More information about the nginx