[Dovecot] Dovecot-2.0 conf misc questions

[Timo Sirainen]

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.