We are using nginx 1.7.3 as a reverse proxy for our Mail SMTP service. For
authentication of each SMTP connection, we have configured nginx to connect
with a http based service for authentication. Here is a snippet of our
# mail server
... other configs...
With above config, we notice that nginx closes the connection after every
auth request/response to Mail Authentication Server (auth_http
auth_host:auth_port/authserver;) based on tcpdump analysis. We would like
to make this connection persistent so that we could reuse connection for
multiple auth requests.
I looked at nginx mail auth module documentation (
) but I don't see any directive to make mail auth connection persistent.
I also looked at ngx_http_upstream_module (
which has "keepalive" directive but my understanding is this directive is
for http upstream server not for mail auth server.
Can someone please help? Thanks!
user: Maxim Dounin <mdounin(a)mdounin.ru>
date: Mon May 15 20:09:44 2017 +0300
Configure: recent Sun C versions.
auto/cc/sunc | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diffs (15 lines):
diff --git a/auto/cc/sunc b/auto/cc/sunc
@@ -8,7 +8,10 @@
# Sun C 5.9 SunOS_i386 2007/05/03 Sun Studio 12
# Sun C 5.9 SunOS_sparc 2007/05/03
# Sun C 5.10 SunOS_i386 2009/06/03 Sun Studio 12.1
-# Sun C 5.11 SunOS_i386 2010/08/13 Sun Studio 12.2
+# Sun C 5.11 SunOS_i386 2010/08/13 Oracle Solaris Studio 12.2
+# Sun C 5.12 SunOS_i386 2011/11/16 Oracle Solaris Studio 12.3
+# Sun C 5.13 SunOS_i386 2014/10/20 Oracle Solaris Studio 12.4
+# Sun C 5.14 SunOS_i386 2016/05/31 Oracle Developer Studio 12.5
NGX_SUNC_VER=`$CC -V 2>&1 | grep 'Sun C' 2>&1 \
| sed -e 's/^.* Sun C \(.*\)/\1/'`
I'd expect to see the original request's port 80 or 443 in this variable
rather than relatively useless (IMHO) CLIENT_PORT which looks like 51501.
A typical use case for this change would look like the following:
1. nginx HTTP server is running behind Amazon Load Balancer in TCP mode
with PROXY PROTOCOL enabled (can be any TCP load balancer with proxy
protocol on, useful for websockets for example)
2. nginx has the proxy_protocol turned on
3. we (or other apps, upstream servers) want to know what was the ORIGINAL
port/protocol of the incoming request (eg. was it 80/HTTP or 443/HTTPS).
Currently it seems that it's impossible to get the request port/protocol
value from nginx behind tcp load balancer. If nginx stored the PROXY_PORT
instead of the CLIENT_PORT value in that (or another) variable it would be
extremely easy for other apps to know the original port/protocol.
listen 80 proxy_protocol;
proxy_set_header X-Forwarded-Port $proxy_protocol_port; # 51505 instead
of 443/80 !!
Please let me know if it's feasible or planned, or if we could actually
read the original incoming request port in a different way
The problem with reading the correct port seems to be with nginx at
src/core/ngx_proxy_protocol.c somewhere between lines 70 and 120 , It just
reads the PROXY line, takes the first IP as the client IP and then skips to
ports and takes the first port. Instead it should skip the first one and
take the last according to Proxy Protocol specs.
See example mentioned before: PROXY TCP4 192.168.0.1 192.168.0.11 56324 443
in course of building up a dataset of mappings of User-Agents and their
common SSL ClientHello messages I started to implement a small patch
to nginx 1.13.0 mainline to implement a small transcript of the
handshake process similar to the one enabled in openssl s_client -msg.
The format of this new variable is a series of semicolon-delimited
blocks starting with a direction (C: -> sent by client, S: -> sent by
server) and followed by colon-delimited hexdumps of processed blocks of
data. The string C:00:01;S:0203:0405:0607;C:08090A; denotes 2 blocks of
1 byte each sent by the client, followed by 3 blocks 2 byte each from
the server and finally 1 block of 3 bytes from the client. Blocks
usually conform to how OpenSSL tries to process the data.
I'd appreciate a short review of the patch with comments for possible
improvements, code style and other related things. One yet open aspect
is configurable behaviour to only enable collection on-demand. Also
ideas for migrating this code into a separate module are welcome.
NB: Due to size of transcribed information it is commonly not feasible
to pass this variable to other backend servers via HTTP headers. Trying
to do so will most likely result in the backend responding 400 Bad
Request, sometimes also remarking about the overlong header. I'm still
looking at ways how this can be done in a sane way (abusing memcached
for transporting could be an option) - but this is outside the scope of
this patch. Plainly logging the information of this header to some
custom log will do just fine.
 Original paper on this approach at