On a multi-domain Virtualmin server using PAM/passwd-based mail auth (passdb=pam, userdb=passwd, auth_username_format = %n), I found that two mailboxes with the same local-part on different domains — e.g. support@domain-a.com and support@domain-b.com — can’t both be used for IMAP/SMTP login.
Both get created as separate Unix accounts (different UID, different home), but since %n strips the domain from the login name, any login attempt for “support@…” always resolves to whichever Unix user was created first. The second mailbox exists and receives mail fine, but is unreachable via IMAP/POP3/SMTP.
Workaround that worked for me: give the second mailbox a different local-part (e.g. helpdesk@domain-b.com) and add a Postfix virtual alias so the original address still redirects there. Switching to %Lu (full address) is not a safe fix on a server with existing accounts, since it breaks any client still logging in with a bare username.
Question: is there a supported way to get unique, domain-qualified Unix usernames per mailbox automatically (without a full switch to SQL-backed virtual mailboxes), or is this just an inherent limit of PAM/passwd mail auth that has to be worked around manually per mailbox?
A default installation does not have the limitation you’ve described. By default, the full user@domain.tld is used.
And, in the case where you don’t always use the full name plus domain, I’d recommend you allow Virtualmin to include the domain to avoid a clash (also a configurable option, when enabled, your first help user will be just help, while subsequent ones will be help@domain.tld).
So, the answer is “no, it doesn’t have to be worked around manually”, there are at least two configuration options that allow it to be fully automated/enforced by Virtualmin. But, the simplest option is to use the fully qualified name always. And, yes, it’s a limitation of a user model in which all users are actual system users. One could argue about whether that’s the right choice today, it made sense at the time, but I think if I were implementing it today, I wouldn’t back mail accounts with a system user.
Generally, you should not modify the Dovecot configuration in this area. It doesn’t control how SASL and Postfix behaves, so it’s easy to get mismatched behavior when trying to send and deliver mail vs trying to retrieve mail. It’s probably not impossible to get some combination of configuration changes to make something good happen, but I’d probably recommend you focus on getting usernames that work, rather than trying to make the various mail components munge the username in exactly the right ways to give the behavior you want.
A system username of joe@virtualmin.com is always joe@virtualmin.com in Dovecot, Postfix, and saslauthd via PAM.
