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