[Dovecot] Proxying, pertinent values and features, SNI

[Timo Sirainen]

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.