dovecot - Apr 2013 - Proxying, pertinent values and features, SNI

Hello,

I'm looking into deploying dovecot as a proxy, currently using perdition.
Have been using dovecot on the actual servers for years, nearly a decade.
So far just 1.x, but for the proxy it will have to be 2.x (2.1.7 is the
current Debian version), as the trigger for this change is the need to
support multiple SSL certificates. 

All that happens on the proxy seems to be handled by the login processes,
so that is why we're not seeing anything useful in the process titles or
with doveadm, right? 
And from past comments by Timo I guess that adding such functionality
isn't on his to-do list at all.

A configurable capabilities string for POP would be quite welcome, but at
least nothing is different between the 1.x backends and the 2.x proxy in
that protocol.
Speaking of 1.x versus 2.x, the feature to pass on the remote IP from the
proxy to the backend is a 2.x thing only, correct?

So I suppose any parameters really affecting this setup are
default_process_limit and default_client_limit as well as the settings 
in service-imap-login and service pop-login. 
In particular mail_max_userip_connections never is looked at on the proxy
as this check happens in the respective protocol AFTER login, rite?

I presume to best support all(?) clients out there is to have
"local_name"
sections for SNI first and then "local" sections for IP address based
certs. It is my understanding that SNI needs to be requested by the
client, so aside from client bugs (nah, those don't exist ^o^) every
client should get an appropriate response for TLS. 
Has anybody done a setup like that already?

Regards,

Christian
-- 
Christian Balzer        Network/Systems Engineer                
chibi at gol.com   	Global OnLine Japan/Fusion Communications
http://www.gol.com/

Hi
> I presume to best support all(?) clients out there is to have
"local_name"
> sections for SNI first and then "local" sections for IP address
based
> certs. It is my understanding that SNI needs to be requested by the
> client, so aside from client bugs (nah, those don't exist ^o^) every
> client should get an appropriate response for TLS.
> Has anybody done a setup like that already?
>
Although not what you asked for, just so you are aware, Godaddy (boo 
hiss, etc) offer reasonably inexpensive multi subject alt name based 
certs.  This means you can have a single cert which is valid for lots of 
completely different domain names.  The mild benefit is that this 
doesn't require SNI support for SSL (which I'm unsure is supported by 
many mail clients?)

Although it's more expensive, I think it's a good solution (I'm
using it
for a small 5 domain installation)

Good luck

Ed W

On 3.4.2013, at 10.59, Christian Balzer <chibi at gol.com> wrote:
> I'm looking into deploying dovecot as a proxy, currently using
perdition.
> Have been using dovecot on the actual servers for years, nearly a decade.
> So far just 1.x, but for the proxy it will have to be 2.x (2.1.7 is the
> current Debian version), as the trigger for this change is the need to
> support multiple SSL certificates. 
> 
> All that happens on the proxy seems to be handled by the login processes,
> so that is why we're not seeing anything useful in the process titles
or
> with doveadm, right? 
> And from past comments by Timo I guess that adding such functionality
> isn't on his to-do list at all.
doveadm proxy list
> A configurable capabilities string for POP would be quite welcome, but at
> least nothing is different between the 1.x backends and the 2.x proxy in
> that protocol.
v2.2 backends actually add some new POP3 capabilities. I guess there could be
such a setting, although it's a bit annoying to develop..
> Speaking of 1.x versus 2.x, the feature to pass on the remote IP from the
> proxy to the backend is a 2.x thing only, correct?
Right.
> So I suppose any parameters really affecting this setup are
> default_process_limit and default_client_limit as well as the settings 
> in service-imap-login and service pop-login. 
> In particular mail_max_userip_connections never is looked at on the proxy
> as this check happens in the respective protocol AFTER login, rite?
Right.
> I presume to best support all(?) clients out there is to have
"local_name"
> sections for SNI first and then "local" sections for IP address
based
> certs. It is my understanding that SNI needs to be requested by the
> client, so aside from client bugs (nah, those don't exist ^o^) every
> client should get an appropriate response for TLS. 
> Has anybody done a setup like that already?
If you have separate IPs for each sertificate, you don't need to
support/configure SNI, so local {} blocks are enough.