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...
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
