Nginx – Why auth_http Entry is Needed for SMTP Reverse-Proxy

authenticationnginxPROXYreverse-proxysmtp

I'm an apache user normally, but I need to start using nginx as a reverse proxy for smtp (postfix).

I've seen tens of examples online. Like this and this. All of them have an auth_http entry, which I completely don't understand. This is not the first time I use proxies, and I currently use haproxy since months. So why do I have to provide a php authentication page? Why can't I just use nginx as simple as I use haproxy, and just tell it: Set a frontend here, decrypt ssl with this key, and take it to that backend/port?

Could someone please explain how necessary that auth_http entry is? The nginx manual doesn't seem to say much.

Thank you for any efforts.

Best Answer

Basically there are three big steps in your workflow

Encryption and decryption process either by STARTTLS or SMTPS
Authentication process i.e. to check if you allowed to do SMTP transaction
SMTP Transcription (MAIL FROM, RCPT TO and so on)

As far as I understand, you want to use nginx to do step 1, and transparently pass the rest of the transaction to the backend. Unfortunately you can't do it with nginx due its design. Nginx is always do step 1 and 2 before pass the request to the backend.

That's why parameter auth_http becomes crucial. Basically nginx takes username and password from SMTP auth process, pass it to auth_http URL via a protocol. And it expects response about auth status (whether transaction can be continued or not) and which address and port where the SMTP data should be passed.

So, if you want just some SSL stripper proxy for SMTP, then maybe nginx won't be fit in your case.

Related Solutions

NGINX Reverse Proxy – URL Rewrite

Any redirect to localhost doesn't make sense from a remote system (e.g. client's Web browser). So the rewrite flags permanent (301) or redirect (302) are not usable in your case.

Please try following setup using a transparent rewrite rule:

location  /foo {
  rewrite /foo/(.*) /$1  break;
  proxy_pass         http://localhost:3200;
  proxy_redirect     off;
  proxy_set_header   Host $host;
}

Use curl -i to test your rewrites. A very subtle change to the rule can cause nginx to perform a redirect.

Nginx – How to debug nginx further than the error log

I'm assuming you've already jacked your Nginx error logging level up to debug. If not, start there.

Your best bet is probably going to be using strace to view the system calls being made by Nginx. In particular, you'll want to pay attention to connect() calls, and keep an eye on the return codes of these (man 2 connect can be your friend here).

Once you have that information, you can better make an educated guess about whether the issue is confined to your frontend proxy, or has something to do with the interactions between the proxy and backend application server.

Best Answer

Related Solutions

NGINX Reverse Proxy – URL Rewrite

Nginx – How to debug nginx further than the error log

Related Topic