Still broken, but I committed the current changes to http://hg.dovecot.org/dovecot-config-rewrite/

The idea is something like:

• src/config/ contains a doveconf binary which can be used to dump the current configuration. It's the only binary that reads dovecot.conf directly. Currently the code is kind of ugly because I wanted it to be able to parse the existing v1.2 dovecot.conf which required some kludging around. Perhaps in v2.0 the dovecot.conf could have larger changes and these kludges could be removed.

• master currently executes doveconf 3 times: for default settings, for imap settings, for pop3 settings. The result is saved into an array of KEY=value pairs in an array. Eventually they're still sent to child processes via environment. This sending via environment is again mainly for backwards compatibility with post-login scripts. Although they are useful there, so I'm not sure if it should be kept that way. Although post-login scripting doesn't really work anymore with Apple's multiple-connections-per-mail-process code, so perhaps that needs some rethinking in any case..

• deliver also currently forks and executes doveconf. I hate this. But I don't like the alternative of having a libconfig that deliver could use to read the configuration inside the binary as is done now, because then it's not as easy anymore to update the doveconf binary (or replace it entirely). But I'm thinking about making doveconf a long running process and deliver could ask configuration from it via UNIX socket if it's running and fallback to forking doveconf.

The last possibility would be not to fork, but instead just have doveconf exec() deliver, so either something like "doveconf -e deliver -deliver-params" or if calling deliver directly it could exec() doveconf which would then exec() deliver back. Hmm. Perhaps this is actually better than forking?

• %variable expansion is somewhat broken with imap/pop3, but works with deliver. The annoying thing about this is that %vars from doveconf should be expanded, but if userdb returns anything containing %vars they shouldn't be (because e.g. home directory could contain %).

So either master should expand everything internally or it should somehow tell child processes about what to expand and what not. It can't really expand everything because it doesn't know all the settings that should be expanded. So that only leaves the possibility of telling child process what to expand.

One possibility is to prefix each environment with e.g. 0 or 1 specifying if it should be expanded. This would break all existing postlogin scripts and in general would make it kind of ugly. Another possibility would be to have an environment that lists the settings that shouldn't be expanded. Perhaps that would work better, although if postlogin script changes/adds environments they'd also potentially have to modify that environment too.

• Plugins will probably have to keep using something similar to getenv() to get their settings. It would be possible to have them use the nice new pre-filled settings structures, but that would require configuration changes. For example instead of quota=.. quota2=.. you'd have two quota {} blocks. Probably better to leave that change to v2.0.

• I'm not entirely sure where all the setting verifications should go. Having them done by master when starting up is nice because it can give error messages immediately and write them to screen, instead of having to look them up from the log. Or when reloading configuration it can cancel it if the new configuration isn't ok. Maybe doveconf could do the checks. Maybe the verifications could go to all the different *settings.c files where they logically belong to, and then the build scripts would copy those functions to doveconf code where it could check all of them when the config is being read. The only annoying thing is that this then required doveconf to be run as root so that it can do all the access() etc. checks. But maybe that's not too bad.