Hello!

On Mon, Jul 06, 2020 at 12:08:50PM -0700, Denis Sh. wrote:

> Thanks Maxim, so
>
> > SNI server name as sent by the client can be passed to the
> > auth_http script if needed, along this other Auth-SSL* headers,
> > this should be simple enough.
>
> you mean with config or changing NGINX code?

Changing the nginx code, of course.

> > But we are yet to see use cases
> > where this is needed
>
> use case - having a front end nodes that would terminate TLS/SSL SMTP/IMAP/POP including
> STARTLS (offloading) using Server Name presented by the clients via SNI and pass traffic
> to the Postfix/Dovecot blackens respectively. The idea is that back-ends won't have to terminate SSL and
> keep all the keys/certs.

Define "using server name paresented by the clients".
Using how?

I see only two possible usage scenario here:

1. Use the sever name to provide appropriate certificate. The
Auth-SSL-Whatever header is not going to help here though. On the
other hand, providing a certificate with multiple names easily
solves this, and also covers clients not using SNI.

2. Use the server name to choose the backend and/or the default
domain name for authentication. This is not going to work for
non-SSL connections though, since, as already mentioned, there is
no concept of name-based virtual hosts in mail protocols.

So, Auth-SSL-Whatever header is only going to help if you are not
going to use non-SSL connections at all, and only helps to provide
some only

> >> So stream certainly won't work for you.  The question is still the
> >> same though: what are you trying to achieve.
>
> yeah, stream would only work for pure TLS, not for STARTTLS,
> same as with HAPROXY by the way.
> I've described the use case above, also there are blog posts on
> the inernets wheere people use NGINX mail proxying
> for transitioning their user base from "old" to "new" platforms,
> allowing them to keep existing configs and names in mail
> client's settings.

It is not clear how SNI is going to help here.

> > SMTP is considered to be a protocol to be handled locally, with
> > authentication details passed via XCLIENT (if at all). You don't
> > need to proxy users to specific backend servers with their
> > mailboxes, an SMTP server running locally (or on dedicated
> > machine) would be enough.
>
> I'm not sure I understand the part where you talk about local or
> dedicated SMTP server?
>
> SMTP is used to send mail and also mail servers talk to each
> other over public internet using it.
> I would not say it's a local only protocol, It's not LMTP.
>
> Also, XCLIENT is an extension, not the standard way of doing
> AUTH, correct me if I'm wrong here.
>
> I'm still curious why NGINX choose not to support passthru AUTH,
> that seems to be logical and aligns with use case.

Probably I wasn't clear enough. Usage model of nginx expects SMTP
backends to be local. A locally running fully-functional SMTP
server such as Postfix would be good enough solution.

The main goal of using nginx in front of a real SMTP server is to
protect the SMTP server from high load, since most, if not all,
SMTP servers out there cannot handle many connections. Additional
goal is to use uniform authentication with IMAP/POP3, so there is
no need to configure / implement authentication in you SMTP
server.

If you aren't happy with using XCLIENT, which is indeed an
extension, you can use no authentication at all - this is
perfectly standard for SMTP - and allow only connections from
nginx. The only downside is that you won't be able to add proper
attribution in headers. On the other hand, without XCLIENT you
won't be able to add proper client's IP address to headers, so you
have to use XCLIENT anyway.

Summing the above: for SMTP you have to use XCLIENT anyway, and
proxying authentication is only needed in some specific use cases
when using nginx to proxy to external SMTP servers. This is
believed to be relatively rare use case and certainly not the use
case nginx SMTP proxying was developed for.

[...]

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx