> On 18/02/2026 23:59 EET sev monster via dovecot <[email protected]> wrote: > > > 8 months ago I messaged this list communicating some of the issues I had with > 2.4. Before I could even start testing 2.4 properly, 2 bugs had to be > fixed—one that caused crashes on startup > (https://gitlab.alpinelinux.org/alpine/aports/-/issues/17050), and one that > caused passdb to use the same caching key for all connections and as such > always have the same user log in. There was another bug, one that prevented > me from using LDAP binds for passdb, but it had a workaround that mostly > worked without side-eeffects. All of those have since been fixed, hurray! > > So in my infinite naïveté, I decided to give 2.4 another shake. And it, > again, does not work. Surprise! > > I did manage to massage the configuration to allow me to at least run 2.4 > without crashing and with users able to access (most of) their mailboxes, but > there are still blockers to full functionality. >
Have you given https://dovecot.org/upgrader a try to see if it can massage your config better? > I face the following issues: > 1. Christian Pfeiffer back in November found a bug where auth caching with > LDAP did not work, and due to how it's implemented, even turning caching off > would still raise an error. I experienced the same issue for both userdb > iteration and passdb bind logins. I had to comment out the userdb and use a > static one instead (all my users, currently, use the same UID and easily > composable path, so this wasn't a big deal) and start using a service account > for LDAP binds. > 2. Virtual mailbox autosubscribe does not work anymore. It throws an error > about trying to create the virtual mailbox. This worked in 2.3. > > My virtual mailbox config: > namespace virtual { > type = private > prefix = Search Folders. > mail_driver = virtual > mail_path = /etc/dovecot/virtual > mail_index_path = ~/dovecot-virtual.cache > mail_control_path = ~/dovecot-virtual.cache > mail_volatile_path = ~/dovecot-virtual.cache > hidden = yes > list = children > subscriptions = no > > mailbox All { > auto = subscribe > special_use = \All > comment = All messages, excluding Junk and Trash > } > > mailbox Unread { > auto = subscribe > special_use = \Important > comment = All unread messages, excluding Junk and Trash > } > > mailbox Flagged { > auto = subscribe > special_use = \Flagged > comment = All flagged messages > } > } > > If there is something wrong with this config that might be responsible for my > issue, please let me know. Otherwise, I believe this is a regression. I > understand autosubscribe is documented to (and in other situations with > non-virtual boxes) create mailboxes if missing, so if this is actually a fix > to make the feature work as documented, we need a new option that allows for > autosubscription without attempting to create the mailbox. Otherwise, my > users will not know they even have these mailboxes—no one anymore knows or > cares about mailbox (re: folder) subscription and won't know where to look to > get them to show up in their client. > > With autosubscribe enabled, I can see the mailboxes in my mail client without > explicitly subscribing, but attempting to open them will throw a server > error. Removing the setting will make the mailbox disappear without going > into settings and explicitly subscribing. > > Any ETA on the first bug being fixed, and any help with the second issue (bug > or not) would be greatly appreciated. > Can you give us a hint what the error was? > Best regards. > > P.S.: I wanted to spread this information that wasn't mentioned at all in the > documentation. The shadow passdb was removed in the move to 2.4; why exactly > is neither here nor there, though I will remark that I still don't know why > it was done. I had believed at the time this necessitated enabling PAM for > Dovecot, which it is not by default in my distro's package (Alpine), so if I > wanted to continue allowing local users to log in, I would have to build > Dovecot it myself and install PAM, neither of which I particularly wanted to > do. I did play with passwd-file in the past, but there were issues with it > that prevented me from using it—I don't remember what they were exactly, but > I believe they have since been fixed, since in my testing now it does seem to > work properly in the use-cases I tested. > > Anyway, while going over my config and getting ready to re-install PAM, I had > a thought. /etc/shadow uses the same format for the first two fields as > /etc/password, and Dovecot still (supposedly) allows for passwords to be used > when reading /etc/password, so wouldn't it be possible to point the driver at > the shadow file? Turns out, yes, it works! I am now able to authenticate > local users from /etc/shadow again. Thanks to this, I no longer need to build > with PAM support and don't need to install PAM on a PAM-less system. I hope > this isn't considered a bug or something and support for this use-case is > removed, because I really don't want to bother once again with adding PAM > when I don't have to. :) No, passwd-file is rather essential so it's not going to go away any time soon. If it works as replacement for shadow, nice. Removal of "shadow" driver is mentioned at https://doc.dovecot.org/2.4.2/installation/upgrade/2.3-to-2.4.html#backends-and-plugins Aki _______________________________________________ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
