[Dovecot] Configuration file changes

Mark E. Mallett mem at mv.mv.com
Wed Jul 2 01:44:53 EEST 2003


> 
> Although I'm still not really sure how this would work either. Currently
> the settings in login group you defined first (imap by default) are used
> as defaults for the second login group (pop3). That's kind of messy I
> think..
> 
> Maybe I should completely drop the login group and rather make protocol
> groups. Something like:

  (etc)

Perhaps some of the confusion is that it looks like you are using
groups as a way both to encapsulate a group of settings and as a way to
override inheritence of global settings.  While those things are
similar it's hard to generalize them by way of nested statements.

On the other hand I could be all wet :-)

(Somebody mentioned BIND9, but it looks more like you have been
reading innfeed conf files.  Bind9 configs are completely block
oriented- innfeed confs have the peculiar line-oriented commands with
block encapsulations).

At any rate perhaps a different way to accomplish parameter grouping
would be to define templates and invoke those templates within
scoped declarations, e.g.:

template standard {
  login_process_size = 16
  login_process_count = 3
  first_valid_uid = 100
  last_valid_gid = 0
}

template wide-open {
  like standard
  first_valid_uid = 0
}

server a {
  like standard		// nested reference to another template
  imap_listen a.b.c.d
   ...
}

server b {
  like wide-open
  imap_listen e.f.g.h
}

I could imagine implementing a "template" as a set of context-free
tag/value pairs.  When invoked (e.g. via "like") the parser would simply
note the reference to the template, and eventually parse the tag/value
pairs when the scope is closed, applying those that had not already
been specifically set.

This may not be what you were thinking about, in which case,
you can ignore it...

-mm-


More information about the dovecot mailing list