On Mon, 2009-08-10 at 13:57 -0400, 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".
I think it's possible to do both:
Use the most specific rule, but if it's also not the first rule, it's a broken configuration and it'll fail. If there are ambiguity in specificity, it's also an error.
(I'm also wondering about if it should be the first rule. Somehow to me it comes more naturally that last settings always override previous settings. If we really want to make first settings come first, then the default settings must be at the bottom of dovecot.conf, or they'd need some exception.)
Require the nesting to be in order:
local_ip { remote_ip { protocol {} } }
Any of the levels could be dropped out, but the ordering couldn't be switched. Then we'll basically require that more specific blocks need to be before less specific blocks, or the configuration reading will fail. (Or vice versa? It somehow seems more natural to me..) The block specificity is determined by the nesting order.
- Simple example:
allow plaintext auth from intranet, except from .123.1
remote_ip 192.168.123.1 { disable_plaintext_auth = yes } remote_ip 192.168.0.0/16 { disable_plaintext_auth = no } disable_plaintext_auth = yes
If the remote_ip blocks were switched, it would give an error.
- More complex example:
Client connecting 192.168.0.1 -> 10.1.2.3.
# this first match is used local_ip 192.168.0.1/31 { remote_ip 10.1.2.0/24 { foo = foo } } # ok, exact match (handle the same as duplicate settings in root, # maybe optionally give a warning about them) local_ip 192.168.0.1/31 { remote_ip 10.1.2.0/24 { foo = foo2 } } # error, local_ip more specific local_ip 192.168.0.1 { foo = xx } # ok, local_ip less specific, remote_ip less specific local_ip 192.168.0.0/16 { remote_ip 10.1.2.0/23 { foo = bar } } # error, remote_ip more or equal specific local_ip 192.168.0.0/16 { remote_ip 10.1.2.3 { foo = baz1 } remote_ip 10.1.2.0/24 { foo = baz2 } } # error, protocol more specific local_ip 192.168.0.0/16 { protocol imap { foo = x } }