Timo Sirainen wrote:
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/
I know, but I assumed only a limited (pre-approved) list of contributors can commit patches, that't why to be honest, I never cared to do a research on your "contribing policy"... which is *presumably* also documented somewhere :-)
Yes, either that or I think fields { noauthenticate = yes } would also work.
I thought noauthenticate refers only to passdb's? To my understanding the effect of this is to just apply any passdb extra fields - notably, even if the password doesn't match - and then do the actual authentication in the following passdbs.
What would be the effect of noauthenticate on a userdb?
Then it would need to be inside protocol lmtp {} or otherwise IMAP auths without domains would fail.
Great, yet another new thing for me - never thought that user/passdb's can be inside filter sections! Does the filtering preserve the cascading order? That is, does this work (pseudo code):
passdb passwd-file-without-domains protocol lmtp { userdb drop-domain-for-valid-domains } userdb same-passwd-file-as-passdb
Or do we need this:
protocol imap { passdb passwd-file-without-domains userdb prefetch-reuse-the-above } protocol lmtp { userdb drop-domain-for-valid-domains userdb passwd-file-without-domains }
I'd argue that parts of this discussion are actually valuable enough (for a non-trivial amount of people) to make it into the documentation...