On 3.4.2013, at 10.59, Christian Balzer <ch...@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.
