SNI support in `mail` context (fixed formatting)

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

SNI support in `mail` context (fixed formatting)

Denis Sh.
Hi!

So, when proxying SMTP/IMAP, is it possible to get the Server Name that mail clients send as a part of Client Hello?

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


Or should I use `stream` to proxy mail?

Any ideas?

Thanks,
Denis
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Maxim Dounin
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
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Denis Sh.
Thank for your reply, Maxim.
 
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?
 
>> 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.
 
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?
 
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" <[hidden email]>:
> 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
> http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Denis Sh.
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?

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

 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?

 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" <[hidden email]>:
>> 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
>> [hidden email]
>> http://mailman.nginx.org/mailman/listinfo/nginx
> ,
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Chris Adams
In reply to this post by Maxim Dounin
Once upon a time, Maxim Dounin <[hidden email]> said:
> 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).

I'm pretty sure that list is out of date - I have Dovecot handling
POP/IMAP for a bunch of domains with SNI and no user complaints.  I'd
lean towards the SNI column being ? because it's just not being checked.

--
Chris Adams <[hidden email]>
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Chris Adams
In reply to this post by Denis Sh.
Once upon a time, Denis Sh. <[hidden email]> said:
>  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?

I looked at adding this, using ID for IMAP and XCLIENT for POP3 (what
Dovecot supports)... didn't get the time and don't need it now, but it
didn't look like it would be too difficult to implement.
--
Chris Adams <[hidden email]>
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Denis Sh.
so, I think passtrhru AUTH IMAP and POP works out of the box now.

It's only SMTP that NGINX never even tries to AUTH against backed.

I wonder why this decision was taken?

06.07.2020, 11:27, "Chris Adams" <[hidden email]>:

> Once upon a time, Denis Sh. <[hidden email]> said:
>>   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?
>
> I looked at adding this, using ID for IMAP and XCLIENT for POP3 (what
> Dovecot supports)... didn't get the time and don't need it now, but it
> didn't look like it would be too difficult to implement.
> --
> Chris Adams <[hidden email]>
> _______________________________________________
> nginx mailing list
> [hidden email]
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Denis Sh.
In reply to this post by Chris Adams
Yeah, It's 2020 after all :)

I think most modern mail client do support SNI and send server name in client hello.

So, Chris, you're saying that you successfully run Postfix and Dovecot that rely on SNI in production?
How bit is your user base, roughly?

Thanks

06.07.2020, 11:21, "Chris Adams" <[hidden email]>:

> Once upon a time, Maxim Dounin <[hidden email]> said:
>>  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).
>
> I'm pretty sure that list is out of date - I have Dovecot handling
> POP/IMAP for a bunch of domains with SNI and no user complaints. I'd
> lean towards the SNI column being ? because it's just not being checked.
>
> --
> Chris Adams <[hidden email]>
> _______________________________________________
> nginx mailing list
> [hidden email]
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Maxim Dounin
In reply to this post by Denis Sh.
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" <[hidden email]>:
> >> 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
> >> [hidden email]
> >> http://mailman.nginx.org/mailman/listinfo/nginx
> > ,
> _______________________________________________
> nginx mailing list
> [hidden email]
> http://mailman.nginx.org/mailman/listinfo/nginx

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Denis Sh.
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" <[hidden email]>:

> 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" <[hidden email]>:
>>  >> 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
>>  >> [hidden email]
>>  >> http://mailman.nginx.org/mailman/listinfo/nginx
>>  > ,
>>  _______________________________________________
>>  nginx mailing list
>>  [hidden email]
>>  http://mailman.nginx.org/mailman/listinfo/nginx
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> [hidden email]
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Maxim Dounin
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
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Chris Adams
In reply to this post by Denis Sh.
Once upon a time, Denis Sh. <[hidden email]> said:
> So, Chris, you're saying that you successfully run Postfix and Dovecot that rely on SNI in production?

No, not postfix - it doesn't support SNI on the server side (and postfix
maintainers are not interested in adding support).  I do have Dovecot
using SNI; at peak it was around 20,000 active users across a couple of
dozen independent service provider domains (lower now as we're migrating
off that whole setup for other reasons).

--
Chris Adams <[hidden email]>
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Svyatoslav Mishyn
(Tue, 07 Jul 11:05) Chris Adams:
> No, not postfix - it doesn't support SNI on the server side (and postfix
> maintainers are not interested in adding support).

FYI, it has SNI support but version should be >= 3.4, see:
http://www.postfix.org/postconf.5.html#tls_server_sni_maps


--
https://www.juef.space/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: SNI support in `mail` context (fixed formatting)

Chris Adams
Once upon a time, Svyatoslav Mishyn <[hidden email]> said:
> (Tue, 07 Jul 11:05) Chris Adams:
> > No, not postfix - it doesn't support SNI on the server side (and postfix
> > maintainers are not interested in adding support).
>
> FYI, it has SNI support but version should be >= 3.4, see:
> http://www.postfix.org/postconf.5.html#tls_server_sni_maps

Thanks for the correction - I wasn't aware they added it.  Hmm, I
usually run CentOS and the OS-provided postfix, which is only up to
3.3.1 on CentOS 8.2... still, something to keep in mind.

--
Chris Adams <[hidden email]>
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx