On 27. Jan 2025, at 19.30, Mike Panev via dovecot <dovecot@dovecot.org> wrote:
Timo Sirainen wrote:
We have a new documentation structure, but I don't know if it's any better regarding that. For some reason people aren't super interested in spending much time on writing documentation. :)
Well, I'd be willing to do that - unfortunately not regularly, as Dovecot is not my day job, but at least when I stumble upon something that takes me hours debugging/analyzing/understanding, then it's not much of a deal to document what you just found out. Actually in such situations I sometimes make my own notes, in case I need it in future. Writing it down usually makes you understand it even better (or realize that you still don't quite get it...). So then I'd just have to commit/post somewhere what I wrote anyway.
Our documentation is written using github pull requests, so anybody can easily do changes as little or as much as wanted. https://github.com/dovecot/documentation/
Another possibility could be to add a new userdb before the real one, which drops the domain for valid domains: userdb drop-domain { driver = passed-file passwd_file_path = /etc/dovecot/valid-domains result_success = continue fields { user = %{user | username} } }
valid-domains file would just list all valid domains, one per line
If I'm understanding your idea correctly, you'd also need "auth_username_format = %{user | domain}" (or "username_format = %d" in the old syntax), right?
Right.
Also, I'd change "result_success" to "continue-fail", because otherwise the overall userdb result will be successful even if the next userdb (containing the actual users) does NOT find the user. This means that anyrandomuser@correctdomain would validate.
Yes, either that or I think fields { noauthenticate = yes } would also work.
Probably we also need "result_failure = return-fail" in order to abort searching if the domain is not found.
Then it would need to be inside protocol lmtp {} or otherwise IMAP auths without domains would fail.
I'm still not quite sure about the new "fields" section - does this replace the old "default_fields" or "override_fields" or both? In the above example, does user rename (dropping the domain part) get executed only if the userdb is successful or always? If it's always executed, then we definitely need "result_failure = return-fail".
fields replaces them all. In passwd-file case its behavior is closer to override_fields. As with v2.3, unsuccessful passdb/userdb lookups don't preserve any extra fields (except I think there are some special case exceptions). So user is only changed on successful lookup.
Yet another possibility could be to use %{if} to drop the domain in the existing userdb passwd-file { auth_username_format }
Another very good idea, actually the simplest one to implement, although probably not the most efficient runtime-wise. (Does that if-expression get re-parsed for every lookup or only once at config load time?)
Variable parsing is now done once by config process and exported in a bit more optimized way to the binary config file. The importing is done then multiple times. Anyway, even if it was parsed multiple times, it would be fast enough not to make any noticeable difference here.