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.
One big idea behind v2.4 config rewrite is that now all settings are global settings. You can add any setting inside any filter { .. } section, although it might get just ignored there.
That's a good idea, although in the short term it's a bit confusing when you're used to the old way of doing things. At least now it's more systematic, and makes userdb/passdb and other section-style settings behave like filters, similar to protocol/local/remote, etc. That's another thing I found confusing at the beginning, that the section syntax is used for like 5 different things, depending on context.
How about your passdb/userdb contains only user@example.com, and then you set auth_default_domain=example.com?
Somehow I always thought the "auth_default_realm" (as it was called before) was only for NTLM/GSSAPI authentications, probably due to the word "realm". Didn't realize it leads to appending @domain for passwd-file authentication. Another example where the new name of the config parameter in 2.4 makes it more intuitive - thumbs up.
Yes, that would be one possible solution in my case. It does mean that the "@domain" has to be repeated in every single line in the passwd-file, but at least you can reuse the same file for authentication and LMTP recipient validation, which eliminates maintaining two separate user lists.
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? 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. Probably we also need "result_failure = return-fail" in order to abort searching if the domain is not found.
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".
But thanks a lot for the pointers! I'll play around with these and see which one works best for me.
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?)
Again, very valuable input, thank you Timo!
Regards, Mike