You are right, and I left out half of my thoughts. I think there should be only a coarse grained concept of "more specific rules" - e.g. a protocol section is more specific than general config, and a local or remote IP restriction is more specific than a protocol section. I think that the values of these context selectors should not define "more specific". Within one of these levels, either conflicting settings should be invalid, But that would prevent the following (intuitive) config from working:
remote_ip 192.168.0.0/16 { foo = bar }
remote_ip 192.168.10.0/24 { foo = baz }
This would need some kind of condition like
remote_ip 192.168.0.0/16 && !192.168.10.0/24 {..}
or something.
or maybe better yet, a "last wins" rule should apply. Or you would indeed use this, which makes the above config easy to write wrongly. (If you swap the conditions). You might still detect that a later directive completely overrides a previous setting in all cases and issue a warning, but this is probably hard to do in general.
An alternative that just occured to me is to always do these kind of "exceptions" in a nested way. The above would then become:
remote_ip 192.168.0.0/16 { foo = bar
remote_ip 192.168.10.0/24 {
foo = baz
}}
which is probably even more intuitive than my first example. This way, the user explicitly specifies which directives can override other directives. This is comparable to having a fixed order of "protocol", "remote_ip", "local_ip" that was proposed somewhere in this thread, but allows the user to pick the order.
This does mean that you might need explicit "else", or "other" clauses, since you cannot mix different selectors on the same level of the hierarchy.
protocol imap { remote_ip 192.168.0.0/24 { foo = bar } } protocol other remote_ip = 192.168.10.0/16 { foo = baz } }
A big downside of this approach is probably that you can't easily add a rule for some remote_ip condition regardless of the protocol to the last example, since that should then be specified in both protocol blocks... So, not sure if this is really a useful suggestion, but perhaps thinking about it will help :-)
Gr.
Matthijs