You might as well consider something slightly more fresh. 2.2.10 is rather old already.
And you should also turn on consistent hashing option.
I'd recommend putting dovecot as proxy in front of the directors, and do any brute force deterring there. You can use e.g. weakforced here if you are using 2.2.27+, but dovecot already does some deterring by stalling failed logins.
Dovecot always does asynchronous logins, as the imap-login and
auth process are separate.
Hey All
I am very new to dovecot ecosystem. Found the software really robust and secure. Kudos to the team!!!
We are setting up dovecot imap servers sharing a single nfs mount point. So to avoid nfs cache issues, we are setting up dovecot director. We are using dovecot version 2.2.10. While going through the documentation of dovecot director I stumbled across the following lines in passdb configuration https://wiki2.dovecot.org/Director
"Note that while this is the simplest director configuration, users will be assigned to a backend before they have been authenticated. A director configured this way can be attacked by sending it a large number of unknown users. To prevent this, the director should be configured to authenticate the user and might make use of a master password to log into the backend servers."
I understand on static passdb config dovecot assigns a user to a machine in the list of backends by using md5(username)%number_of_mail_servers. But other than this calculation it does not incur any other resources. It does have tcp connection with the system which is trying to do bruteforce. If we move to authenticating users directly at the director server, the director servers imap-login director service should be anyways loaded on an attack. Is it anything to do that the imap-login will contact auth process asynchronously and keep itself free? I am pretty sure I am overlooking some point on the above statement. Can somebody throw some light on that?