On Mon, Mar 22, 2010 at 01:52:55PM +0000, Naresh V wrote: > Bron Gondwana <brong <at> fastmail.fm> writes: > > [...] > > > > Why does the auth fail on the backend server? It never should. If it does > > that means you've screwed up pretty badly. You can give the failure from > > nginx by just passing an Auth-Status header. > > > > It fails on the backend server when the password that went in in the first place > is wrong. > > I think nginx is at fault here since it considers the AUTHENTICATIONFAILED > response from the (dovecot) IMAP server as an invalid response. > > 2010/03/22 13:36:27 [info] 19575#0: *2 client <IP1> connected to 0.0.0.0:143 > 2010/03/22 13:36:34 [error] 19575#0: *1 upstream sent invalid response: "NO > [AUTHENTICATIONFAILED] Authentication failed."while reading response from > upstream, client: 127.0.0.1, server: 0.0.0.0:143, login: "email@xxxxxxxxxx", > upstream: yy.yy.yy.yy:143 > > (telnet session: > > * OK IMAP4 ready > a login email@xxxxxxxxxx wrongpassword > * BAD internal server error > Connection closed by foreign host. > ) > > Email clients such as thunderbird 3 or opera's M2 have trouble making sense of > such behaviour by nginx and don't even attempt to pop up the authentication > dialog box again. What on earth is your nginx authentication agent doing withat that login? Is it returning "this password is correct"? No wonder nginx is confused. You're _supposed_ to be checking the password before it gets passed to the backend. Make a proper nginx authentication agent and you'll be fine. Bron. ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
