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