On the UCS there are defined 4 mail domains, all user accounts get primary mail addresses/mailboxes in those domains. Some users have defined aliases. Since the upgrade to 5.2 additional maildirs for aliases are created in the top level directory, they are always empty. Deleting thos obviously useless maildirs will lead to re-creation.
Created attachment 11297 [details] Dovecot debug log
Tracking down the issue: - Only users with aliased mailboxes are affected - The problem exists only with dovecot user lookup, not with lmtp Have a look at the joined debug log: Mär 06 16:05:20 ucs dovecot[449038]: imap(<user_name>)<454171><T7ah1a0vCsDAqGTL>: Debug: Namespace inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:/var/spool/dovecot/private//<user_name>/Maildir Mär 06 16:05:20 ucs dovecot[449038]: imap(<user_name>)<454171><T7ah1a0vCsDAqGTL>: Debug: maildir++: root=/var/spool/dovecot/private//<user_name>/Maildir, index=, indexpvt=, control=, inbox=/var/spool/dovecot/private//<user_name>/Maildir, alt= The LDAP lookup results in //<user_name> instead of /<mail_domain>/<local_part> I couldn't track down so far the failing LDAP lookup. The problem is a major annoyance, because mail clients are regularly reloading the complete mailbox after showing initially empty mailboxes after some operations such as sending a mail.
We've got the same problem. Our temporary fix is to create symbolic links at the top level dir to the matching directory (user.name → domain/user.name). Please let me know if I can do anything to help with debugging.
It seems that this is a known problem with the auth cache in dovecot (https://help.univention.com/t/dovecot-seltsame-userordern-im-hauptverzeichnis/9849). On of my colleagues condensed the workaround in a help article: https://help.univention.com/t/problem-dovecot-userdb-cache-causing-incorrect-home-directory-on-cached-imap-logins/24477
If this issue should really be related to Dovecots userdb cache, I am still wondering why it appeared on upgrade of an existent installation to 5.2 (according to the links it existed already in UCS 4.0/4.2). Does there exist an issue on dovecots bugtracker?
Sound implausible to me as well, that a bug in dovecot which once was fixed (in older Debian versions) just re-occurred. And I don't see that we have patches for dovecot. So we also didn't forget to re-apply a patch from UCS 4 ind UCS 5. It would help, if somebody could test the workaround and say if that works.
(In reply to Florian Best from comment #9) > It would help, if somebody could test the workaround and say if that works. We've got feedback from our customer in #2025082221000153, that the workaround (disabling the cache) worked and no problems occured since then (~6 days).
(In reply to Florian Best from comment #9) > It would help, if somebody could test the workaround and say if that works. I can confirm as well, that disabling dovecots auth cache seems to work and no additional maildirs are created.
9dfd50f003 Bug #57976: Advisories e2e00fe7e9 Bug #57976: Adjust test timeout 1adaaa2dcf Bug #57976: Change greylisting script to use mailPrimaryAddress as auth validation a6e57e40a0 Bug #57976: Create test for login against dovecot 1cf862cb33 Bug #57976: Remove pam univentionmailcyrus 38c3d9823a Bug #57976: Fix authentication using mailaddress in postfix facbcc3984 Bug #57976: Fix authentication using mailaddress in dovecot Package: univention-mail-postfix Version: 16.3.0 Release: 5.2-0 Scope: errata5.2-3 Package: univention-mail-dovecot Version: 8.3.1 Release: 5.2-0 Scope: errata5.2-3 Package: univention-pam Version: 15.3.1 Release: 5.2-0 Scope: errata5.2-3 The reason for the additional mail directories was some confusion between the dovecot cache and the information it gathered from the authentication modules. Since forever, we have a PAM module used in dovecot and postfix that translates the mailPrimaryAddress when used during authentication to a username. If this translation happens (and the dovecot auth cache is already filled, thus no additional LDAP lookup is done), then dovecot regards the user identity as "username" instead of "mailPrimaryAddress". If the behaviour change is due to a difference in dovecot or in PAM is unclear. But this confusion only happens because we harshly translate the address to a username every time. Since using sssd this is not necessary anymore. We now configure sssd so that it can authenticate the user also using the mailPrimaryAddress. Thus the translation is not needed anymore. We were able to reduce the complexity of the pam configuration as well as remove obsolete code, while fixing the issue without having to disable the auth cache of dovecot. Disabling the auth cache of dovecot results in 2x slower authentication, so we highly recommend enabling the cache after the fixed packages are installed.
QA: Code changes: OK Advisories: OK Login after receive a mail, do not create a new mailDir: OK OX Functional account works: Fail but don't apply to this bug see #58699 ~ After upgrade from 5.0 works ~ New installation don't work
<https://errata.software-univention.de/#/?erratum=5.2x261> <https://errata.software-univention.de/#/?erratum=5.2x262> <https://errata.software-univention.de/#/?erratum=5.2x263>
(In reply to Julia Bremer from comment #16) > 9dfd50f003 Bug #57976: Advisories > e2e00fe7e9 Bug #57976: Adjust test timeout > 1adaaa2dcf Bug #57976: Change greylisting script to use mailPrimaryAddress > as auth validation > a6e57e40a0 Bug #57976: Create test for login against dovecot > 1cf862cb33 Bug #57976: Remove pam univentionmailcyrus > 38c3d9823a Bug #57976: Fix authentication using mailaddress in postfix > facbcc3984 Bug #57976: Fix authentication using mailaddress in dovecot > > > Package: univention-mail-postfix > Version: 16.3.0 > Release: 5.2-0 > Scope: errata5.2-3 > > Package: univention-mail-dovecot > Version: 8.3.1 > Release: 5.2-0 > Scope: errata5.2-3 > > Package: univention-pam > Version: 15.3.1 > Release: 5.2-0 > Scope: errata5.2-3 > > > The reason for the additional mail directories was some confusion between > the dovecot cache and the information it gathered from the authentication > modules. > Since forever, we have a PAM module used in dovecot and postfix that > translates the mailPrimaryAddress when used during authentication to a > username. > > If this translation happens (and the dovecot auth cache is already filled, > thus no additional LDAP lookup is done), then dovecot regards the user > identity as "username" instead of "mailPrimaryAddress". > If the behaviour change is due to a difference in dovecot or in PAM is > unclear. > > But this confusion only happens because we harshly translate the address to > a username every time. > Since using sssd this is not necessary anymore. > We now configure sssd so that it can authenticate the user also using the > mailPrimaryAddress. Thus the translation is not needed anymore. > We were able to reduce the complexity of the pam configuration as well as > remove obsolete code, while fixing the issue without having to disable the > auth cache of dovecot. Disabling the auth cache of dovecot results in 2x > slower authentication, so we highly recommend enabling the cache after the > fixed packages are installed. Confirmed: deployed 5.2-3 errata263, reactivated the auth cache, no more additional maildirs. Thanks!