Maxime,

Thanks so much. This was the key:
> Note that this must be an IP address, not a hostname.
My mail server was passing me a hostname, which nginx passed to the authenticate service. I had assumed it was fine to return a hostname.
Returning the IP instead did the trick.

I have now the proxy working inbound and outbound.

Much appreciated also your clarifications regarding the low open file resource and server_name.

You were of a big help today.

Laurent

On Oct 24, 2012, at 6:54 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Wed, Oct 24, 2012 at 05:38:29PM -0400, Laurent Bonetto wrote:
>
>> I did understand you meant to change the number of
>> worker_connections. The only reason why I had lowered it was
>> that I got a warning:
>> nginx: [warn] 1024 worker_connections exceed open file resource limit: 256
>
> This indicate that you have very low open file resource limit set.
> Easiest way to fix this is to use worker_limit_nofile nginx
> configuration directive, see here:
>
> http://nginx.org/r/worker_limit_nofile
>
> Of course tuning your OS and/or using ulimit will do the trick as
> well. Using worker_connections set to something like 128 will
> help as well, but it's just to low for any real work and may be
> only used for testing.
>
>> After pointing my mail client to localhost, I was finally able
>> to see nginx hit my mock for an authentication request so there
>> is definitely some progress! Unfortunately, the proxying is
>> still not working. More precisely:
>>
>> nginx hits my authenticate mock server with:
>> Host: localhost
>> Auth-User: <my user name>
>> Auth-Pass: <my password>
>> Auth-Protocol: pop3
>> Auth-Login-Attempt: 1
>> Client-IP: 192.168.1.104
>> - If my mock responds with
>> < HTTP/1.1 200 OK
>> < Content-Type: text/html
>> < Auth-Status: Invalid login or password
>> < Auth-Wait: 3
>> < Content-Length: 0
>> Then my mail client tells me that I have the incorrect username or password, as expected.
>>
>> - However, if my mock responds with:
>> < Auth-Status: OK
>> < Auth-Server: <my mail server>
>> < Auth-Port: 110
>> The the mail client responds with an internal server error.
>> I added the Auth-Pass (which should not be needed anyway) in the
>> response and that didn't help.
>
> Do you return response without http response line, i.e.
> "HTTP/1.1 200 OK"?
>
> What's exactly in the Auth-Server header returned? Note that this
> must be an IP address, not a hostname.
>
>> Since I didn't see any error in the error.log from nginx I used
>> wireshark to monitor traffic. I filtered on tcp.port eq 110 and
>> compared side by side the traffic coming from an account using a
>> direct connection to my mail server, and an account going
>> through the nginx proxy. In the second case (through proxy), I
>> do not see any traffic going out to my mail server, suggesting
>> it does not get the info it was expecting from my authentication
>> service.
>>
>> - Can you think of something I am missing?
>> - How do I even go about debugging what's happening here apart
>> from what I am already doing (using wireshark)?
>
> Appropriate errors should be logged by nginx into error log. I
> would suggests there should be something like
>
> 2012/10/25 02:29:10 [error] 64793#0: *1 auth http server 127.0.0.1:8081 sent invalid server address:"foobar" while in http auth state ...
>
> this time. It's strange you don't see anything.
>
> Detailed debug information may be obtained using debug log, see
> http://nginx.org/en/docs/debugging_log.html.
>
> [...]
>
>> mail {
>> # I assume server_name comes from Auth-Server so I tried commenting out. Same behavior.
>> server_name <my mail server>;
>
> Just a side note: server_name is needed mostly to present
> something to a client when it connects, see here:
>
> http://nginx.org/en/docs/mail/ngx_mail_core_module.html#server_name
>
> It can't be from Auth-Server as it's only available later, after
> auth http service request. It should be safe to omit it though,
> machine hostname will be used by default.
>
> [...]
>
> --
> Maxim Dounin
> http://nginx.com/support.html
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx