On 05/03/2025 5:31 AM MDT Diego Alvarez via dovecot <dovecot@dovecot.org> wrote:
In Dovecot docs (https://doc.dovecot.org/2.3/configuration_manual/ authentication/caching/) we see:
- User logs in with password Y. The cached password X doesn’t match Y and the previous authentication was unsuccessful, so Dovecot doesn’t bother doing another backend passdb lookup (until cache TTL expires). The login fails.
Anyone knows why they chose this design ? Why not simply do a passdb lookup instead of waiting for cache TTL to expire ?
You didn't copy and paste the whole context of this documentation comment:
https://doc.dovecot.org/2.4.1/core/config/auth/caching.html#early-change
When looking at the full context, this is a situation where a user is either using a password that isn't yet valid (= a bad password, so it's a valid denial), or the user did change their password but the Dovecot system doesn't see the change for some reason (= server/admin issue).
In the above situation, doing a passdb lookup without waiting for cache TTL expiration is simply the same situation as not having a negative cache at all. So either don't use the negative cache or fix the password sync (and if you can't fix the authentication sync delay, you can't use a negative cache).
An unlikely situation is that the user is using the wrong password originally, and then changes their password to this wrong password. You can always reduce the negative cache TTL if you want to catch this rare situation, at the cost of a lower cache hit rate more generally.
michael