Configuring nginx as mail proxy

Laurent Bonetto lbonetto at
Thu Oct 25 01:33:29 UTC 2012


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.


On Oct 24, 2012, at 6:54 PM, Maxim Dounin <mdounin at> 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:
> 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:
>> - 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 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 
> [...]
>>  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:
> 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
> _______________________________________________
> nginx mailing list
> nginx at

More information about the nginx mailing list