SMTP proxy and authentication on backend

Fabio Grasso fabio.grasso at
Mon May 4 09:28:16 UTC 2020

Hello there,
I'm new to this mailing list, so hi everybody ;-)

I'm implementing a mail proxy based on nginx. I wrote an
authentication backend in LUA and it works fine.

With IMAP I've no problem, everything works fine.

With SMTP I'm facing the well noted "limitation" about the
authentication on the backend. I know that nginx doesn't pass username
and password when proxying SMTP connection (unlike what happens with
POP3 / IMAP) and this is creating problems for me.
My SMTP server is based on HCL Domino, I can configure it for accept
connections from nginx without relay check but this still creates a
security problem for me: I cannot prevent someone from sending e-mails
by declaring a sender other than the one they logged in with

>From what I understand the only thing that supports nginx is XCLIENT,
which however is not supported by HCL Domino (from what I found it
seems that it is supported only by postfix and derivatives).

I'm a bit surprised that nginx doesn't support autentication on SMTP
backend (at least with an option for enable or disable it), since this
limitation was reported 10 years ago (i.e. I've found this message:

I'm looking for solution and so I'm asking you if you have any suggestions.

I was thinking about two main option:

1) insert a postfix between my reverse proxy and my mail server. But
this will add some complexity and another (useless) hop.
Moreover I need to manage somehow sorting mail on postfix by domain
(the one that sends my authentication server in the Auth-Server /
Auth-Port header). Is there any way to pass this information to
postfix, for example by including it in XCLIENT?
I see that XCLIENT also supports DESTADDR and DESTPORT as attributes,
but it doesn't seem to me that there is any way to set nginx to use

2) I found some "patches" for nginx that add this functionality, for example:

Are there experiences on this? Can they be considered stable?

It is not a problem to compile nginx with these changes, what worries
me however is that any changes in the source in the future may not
work with this patch and in fact risk of limiting myself the
possibility of keeping the version of nginx updated (with all the
consequences in case of major security patches)

Files touched are not so frequently changed on official nginx code:
src/mail/ngx_mail.h and src/mail/ngx_mail_proxy_module.c  have the
last commit 5 years ago, but obviously I have no guarantee that they
will not be changed in the future...

2bis) this is a curiosity: why were these patches never included in
the nginx code?
I see that the I'm not the only one facing this limitation, there are
a lot of reference, like these:

Anyone has expierience with this? How have you solved?


More information about the nginx mailing list