On Wed, 2010-06-23 at 16:54 +0200, Thomas Hummel wrote:
> Hello,
>
> I'm setting up a dovecot-2.0.beta6 install and I'm experiencing the
> following issues/questions :
>
> 1. Converting the config file
>
> # /usr/local/dovecot-2/bin/doveconf -n -c
> /usr/local/dovecot-1.2.12/etc/dovecot.conf :
>
> [...]
> doveconf: Fatal: Error in configuration file
> /usr/local/dovecot-1.2.12/etc/dovecot.conf line 176: Unknown setting:
> process_limit
This was caused by the old settings translator. What was in line 176?
Did you have managesieve installed for v1.2?
> 2. Changing the process limit
>
> In 10-master.conf, I changed 'service imap''s 'process_limit' from 1024 to
> 4096 which caused :
>
> Warning: service auth { client_limit=4096 } is lower than required under
> max. load (5320)
>
> Where does the 5320 come from ?
imap process_limit + pop3 process_limit + whatever other protocols you
have enabled and + their process_limit.
> 3. The = <file syntax
>
> Is there anything to know about this new syntax other than files are
> introduced by "<" ?
Nope. Well, if you don't want to use files, you can also do:
ssl_cert = ----- BEGIN CERTIFICATE ----- \
line2 \
line3 \
etc.
> 4. The "filter" hierarchy
>
> My understanding is that protocol, remote, local must be specified in the
> following order
>
> protocol name {
> remote <ip|name> {
> local <ip|name> {
I think remote is under local, but you'll anyway get an error message if
you try the wrong order.
> and that for a match in several blocks, the more specific wins.
Yeah.
> but it's not clear to me where they are valid
Almost everywhere, except where they don't make sense anyway. Currently
auth settings don't support local/remote blocks, but that should get
fixed some day.
> and if we can negate (with a ! for instance) an argument.
protocol !imap {
}
works. But local/remote doesn't support it.
> For instance, I want to implement the typical case of "let clients from the
> inside network perform a plain auth over a clear connection, require SSL
> before
> auth for the outside network clients".
>
> For that, I want to put
>
> remote <internal network address> {
> disable_plaintext_auth = no
> }
>
> in 10-auth.conf
>
> and let the 'disable_plaintext_auth = yes' in dovecot.conf
That should work.
> But :
>
> . why is this default not in 10-auth.conf file ?
You mean why isn't there an example remote {} block there? Disabling
plaintext auth even for internal network isn't such a great idea..
> . would I have been allowed to do, for instance, in that file at the same
> line
>
> protocol imap {
> remote <internal network address> {
> disable_plaintext_auth = no
> }
>
> ?
Yes.
> . would I have been allowed to do, for instance, in that file at the same
> line
>
> protocol ! imap ...
yes.
> or
> remote ! <some address>
no.
> Besides, if I set ssl=required, do I still need disable_plaintext_auth = yes ?
If you only use plaintext authentication mechanisms (which people
usually do), the ssl=required and disable_plaintext_auth=yes are
equivalent. The difference comes only if you use e.g. CRAM-MD5 etc.
> 4. auth unix listner
>
> Default is the unix socket 'auth-userdb'. Which processes communicate
> through this one ?
1) dovecot-lda
2) imap, when using shared mailboxes and referring to other users' mails
via their home directory
3) doveadm user
.. maybe others..
> Does that mean the the auth process is not the
> process which performs the actual passdb/userdb lookup ?
No. It's a "userdb client" socket.
> Same question : what is the auth-client socket used for ?
For authentication ("is this user+pass correct?"), usually used by MTAs
for SMTP AUTH.
> Finally, would it make sense to declare other auth listeners than the two
> listed by default in the 10-master.conf file ?
The defaults also have one example auth(-client) socket commented out
for Postfix. You can create more of them if you want, but unless
something actually uses them they're a bit pointless.
