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.
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.
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. :)
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
