[Dovecot] v2.0 configuration parsing

Michael Orlitzky michael at orlitzky.com
Mon Aug 10 21:22:02 EEST 2009


Timo Sirainen wrote:
> I'm trying to figure out how exactly v2.0 should be parsing
> configuration files. The most annoying part is if it should always just
> "use whatever comes first in config" or try some kind of a "use most
> specific rule". The "most specific" kind of makes more sense initially,
> but then you start wondering how to handle e.g.:
> 
> 1) User logs in to imap from 192.168.0.1. What is foo's value?
> 
> protocol imap {
>   remote_ip 192.168.0.0/16 {
>     foo = foo
>   }
> }
> remote_ip 192.168.0.0/24 {
>   foo = bar
> }
> 
> 2) User logs in from 192.168.0.1 to 10.1.2.3. What is foo's value?
> 
> local_ip 192.168.0.1 {
>   remote_ip 10.1.2.0/24 {
>     foo = foo
>   }
> }
> remote_ip 10.1.2.3 {
>   local_ip 192.168.0.0/24 {
>     foo = bar
>   }
> }
> 
> Any thoughts?

I think the easiest scheme to keep in my brain would be to evaluate the 
blocks, in order, as if they were branches in code. Fooling around with 
an arbitrary order of evaluation/specificity would be a recipe for 
disaster (see, for example, any CSS engine).

So, something like,

   protocol imap {
     remote_ip 192.168.0.0/16 {
       foo = foo
     }
   }

would translate to,

   if (protocol == imap) {
     if (remote_ip matches 192.168.0.0/16) {
       foo = foo
     }
   }

and then later,

   remote_ip 192.168.0.0/24 {
     foo = bar
   }

would set the value of 'foo' to 'bar', since it would evaluate in a 
similar fashion, and comes later in the config file.

It's easy to explain, easy to implement, and easy to debug. Ultimately, 
the users are going to have to understand how it works in order to 
configure Dovecot properly. "Put the most general rules first, and then 
override them" is a practice with which most of us are already familiar.


More information about the dovecot mailing list