SNI support in `mail` context (fixed formatting)

Mon Jul 6 19:08:50 UTC 2020

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?

> 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.

>> 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.

> 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.

> There are pending patches to allow SMTP proxying to work more like
> other protocols if requested, though these needs someone to review
> them, and given low priority of mail proxying it is unknown when
> this is going to happen.

Oh, so other people already proposed that, I think I saw some proprietary products that might be based on NGINX that actually
implemented this.

Denis

06.07.2020, 11:52, "Maxim Dounin" <mdounin at mdounin.ru>:
> Hello!
>
> On Mon, Jul 06, 2020 at 11:07:56AM -0700, Denis Sh. wrote:
>
>>  Thank for your reply, Maxim. Sorry, I screwed with HTML formatting!
>>
>>   What are the chances that you would look into adding these variable into mail module in upstream?
>>   Looks like it's not very hard to do. Or SNI for mail is not considered to be a real thing?
>
> There are no variables in the mail module, and it's unlikely we'll
> add any in the short-term perspective.
>
> 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. But we are yet to see use cases
> where this is needed (and this is not going to help to provide
> different certificates for different names).
>
>>  >>> But if the goal is to provide
>>  >> different certificates to different names requested via SNI in
>>  >> SMTPS and IMAPS connections
>>
>>   I'm afraid I need to support STARTTLS and either completely do AUTH on NGINX or backends.
>
> So stream certainly won't work for you. The question is still the
> same though: what are you trying to achieve.
>
>>   Also, I wasn't able to find a reason why NGINX intentionally
>>   doesn't support passing thru the AUTH to the backend for SMTP,
>>   same as with IMAP/POP?
>
> 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.
>
> There are pending patches to allow SMTP proxying to work more like
> other protocols if requested, though these needs someone to review
> them, and given low priority of mail proxying it is unknown when
> this is going to happen.
>
>>   Yeah, I know that SNI for mail protocols is a "grey" area,
>>   still want to start implementing it.
>>
>>   Denis
>>  >
>>  > 06.07.2020, 10:32, "Maxim Dounin" <mdounin at mdounin.ru>:
>>  >> Hello!
>>  >>
>>  >> On Mon, Jul 06, 2020 at 10:17:31AM -0700, Denis Sh. wrote:
>>  >>
>>  >>>  So, when proxying SMTP/IMAP, is it possible to get the Server
>>  >>>  Name that mail clients send as a part of Client Hello?
>>  >>
>>  >> Currently no.
>>  >>
>>  >>>  Similar to Embedded Variables for ngx_http_ssl_module:
>>  >>>  $ssl_server_name
>>  >>>  returns the server name requested through SNI (1.7.0);
>>  >>>
>>  >>>  I don't see these vars defined here https://github.com/nginx/nginx/blob/829c9d5981da1abc81dd7e2fb563da592203e54a/src/mail/ngx_mail_ssl_module.c#L229
>>  >>
>>  >> There is no variables in the mail module.
>>  >>
>>  >>>  Or should I use `stream` to proxy mail?
>>  >>>
>>  >>>  Any ideas?
>>  >>
>>  >> This depends on what you are trying to achieve. For obvious
>>  >> reasons stream won't work for complex protocol-dependent things,
>>  >> such as STARTTLS or authentication. But if the goal is to provide
>>  >> different certificates to different names requested via SNI in
>>  >> SMTPS and IMAPS connections, proxying via the stream module with
>>  >> ssl_preread (http://nginx.org/r/ssl_preread) might work for you.
>>  >>
>>  >> Note though that in general there is no concept of name-based
>>  >> virtual hosts in mail protocols, and using name-based virtual
>>  >> hosts for SSL might not be a good idea either. Also, status of
>>  >> SNI support by email clients varies, and "unknown" in most cases
>>  >> (https://en.wikipedia.org/wiki/Comparison_of_email_clients).
>>  >>
>>  >> --
>>  >> Maxim Dounin
>>  >> http://mdounin.ru/
>>  >> _______________________________________________
>>  >> nginx mailing list
>>  >> nginx at nginx.org
>>  >> http://mailman.nginx.org/mailman/listinfo/nginx
>>  > ,
>>  _______________________________________________
>>  nginx mailing list
>>  nginx at nginx.org
>>  http://mailman.nginx.org/mailman/listinfo/nginx
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx