Dovecot splits authentication from mailbox identity for a reason
Dovecot splits authentication from mailbox identity for a reason Dovecot separates authentication into passdb and userdb lookups. Passdb establishes whether the password or authentication mechanism succeeds. Userdb sup
Dovecot splits authentication from mailbox identity for a reason
Dovecot separates authentication into passdb and userdb lookups. Passdb establishes whether the password or authentication mechanism succeeds. Userdb supplies the mailbox identity and the fields that determine where and how the user is served. Treating those lookups as one undifferentiated login can hide a permission bug.
The current documentation supports multiple passdb and userdb backends. A failed password can fall through to the next passdb, while a user lookup uses its own query or prefetch path. That flexibility is useful for migrations and external identity providers, but it makes ordering and fallback behavior part of the security policy.
Review the effective identity
For each mail domain, record the passdb source, userdb source, password scheme, allowed network, master-user setting and the fields returned to the mail process. The userdb result should be stable and specific. A query that returns a wildcard home, an unintended UID or an empty username can turn a valid password into access to the wrong mailbox metadata.
allow_nets can restrict where an authentication succeeds. Test it with a permitted source, a denied source and a proxied connection. A reverse proxy or load balancer may collapse several client networks into one address, so verify the address Dovecot actually sees. Do not trust an X-Forwarded-For header unless the proxy chain is explicitly configured and strips client-supplied values.
Master users need exceptional review
Master authentication can be a recovery and migration tool. It can also bypass the normal mailbox boundary if the master username pattern, password database or allowed network is too broad. Keep master users out of normal service accounts, restrict them to named administrators and audit their use. Test whether a master login can reach a tenant it should not.
Multiple databases should agree on the canonical user name and domain. LDAP-to-SQL migrations often fail on case folding, domain aliases or duplicate records. Run a full authentication test with doveadm auth login and compare the returned userdb fields, not just the success message.
Make failures observable
Log authentication result, backend name, source network and stable user identifier without logging passwords or tokens. Alert on repeated failures, unexpected master-user logins and successful authentication from a network that was removed from policy.
After a suspected account compromise, disable the identity at the identity provider, invalidate active sessions where supported, rotate credentials and inspect mailbox access. Correcting one passdb row is not enough if another backend still accepts the same user or if cached authentication keeps the old decision alive.
The design goal is straightforward: one canonical mailbox identity, an explicit authentication path and a test that proves both agree.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.