Yes, I do. The relevant part of my config is:
ldap_uris = ldaps://ldap.rev-crew.info ldap_auth_dn = cn=dovecot,ou=Services,dc=rev-crew,dc=info ldap_auth_dn_password = ... ldap_base = dc=rev-crew,dc=info
passdb ldap { driver = ldap ldap_filter = (&(objectClass=mailRecipient)(mailRoutingAddress=%{user})) passdb_ldap_bind = yes fields { user=%{ldap:mailRoutingAddress} } }
userdb static { fields { uid=vmail gid=vmail home=/var/mail/vmail/%{user | domain}/%{user | username} } }
#userdb ldap {
driver = ldap
iterate_filter = (objectClass=mailRecipient)
passdb_ldap_bind = yes
iterate_fields {
user=%{ldap:mailRoutingAddress}
}
#}
The second, commented out userdb is just for iterating users, just like in the documentation. In my use case, I don't need need to dynamically look up attributes from the user, so I'm using a static userdb for that, but to be able to iterate users, that second userdb would be needed. I've commented it out for the moment to keep things running.
-----Original Message----- From: Timo Sirainen <timo@sirainen.com> Sent: 06 November 2025 10:52 To: cpfeiffer@rev-crew.info Cc: dovecot@dovecot.org Subject: Re: 2.4.2 breaks user iterations for LDAP
On 6. Nov 2025, at 2.52, cpfeiffer--- via dovecot <dovecot@dovecot.org> wrote:
Hello everyone,
Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed.
It's also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database.
This is however an issue for user iteration with LDAP, as documented here [1]LDAP | Dovecot CE. Such a userdb only has iterate_filter fields that would inherently not be containing any user variables.
Do you have a separate userdb now for ldap userdb lookups? That was the intention at least that usually the userdb filter and iteration would be in the same userdb, not separate ones. Anyway, I'll try to figure out a fix.
I guess that's not saying it very clearly.