On 8.4.2014, at 16.54, Daniel Parthey <d.part...@metaways.de> wrote:
> the Dovecot Director determines the backend host in some way by hashing the
> username:
>
> http://wiki2.dovecot.org/Director
>
> For normal logins usern...@example.org, the director always gets the same hash
> for the same username and ensures that the login is always proxied to the
> same backend.
>
> But what about MasterUsers in combination with Dovecot Director?
>
> http://wiki2.dovecot.org/Authentication/MasterUsers
>
> Which configuration directives should be used to make sure that logins
>
> usern...@example.org*masterus...@example.org
> usern...@example.org*masterus...@example.org
> usern...@example.org*masterus...@example.org
>
> go to the same mailbox backend, in order to avoid NFS caching
> conflicts for mailbox usern...@example.org which should always
> reside on the same NFS client?
>
> Is the master user cut off from behind the master_user_separator?
Yes, assuming your director (not backend) is configured with
auth_master_user_separator=*. It's translated into SASL PLAIN authentication
for backends where director hashes only the username.
> How is the director hash exactly calculated?
> Can the director hashing algorithm be configured in some way?
director_username_hash can be used for configuring.
BTW. There are also some kludgy things you can do with this if you need some
weird setup, such as using user@domain1@domain2 style usernames where
director_username_hash = %{username}@%{domain_first} and then you can use the
%{domain_last} variable in the backend to do some extra stuff. For example if
you want to have @readonly user with readonly ACLs.
