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've now implemented the "use most specific rule".
The "most specific" kind of makes more sense initially, but then you start wondering how to handle e.g.:
- 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 }
Error in configuration file /usr/local/etc/dovecot/dovecot.conf line 2: remote_ip must not be under protocol
Switching around protocol and remote_ip makes it work, I think it's pretty clear then what should happen (foo=bar always with 192.168.0.*):
remote_ip 192.168.0.0/16 { protocol imap { foo = foo } } remote_ip 192.168.0.0/24 { foo = bar }
- 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 } }
Error in configuration file /usr/local/etc/dovecot/dovecot.conf line 7: local_ip must not be under remote_ip
Then if you switch around the remote_ip and local_ip it'll start up normally. But when you log in from 192.168.0.1 -> 10.1.2.3 it'll log an error and fail:
Conflict in setting foo found from filter at /usr/local/etc/dovecot/dovecot.conf:7
So this is a runtime error. It would be possible to test out all the different combinations at startup, but with complex configs that might start taking forever..
Currently it doesn't tell where the other side of the conflict came from. It probably wouldn't be too difficult to add, but I think I'll just leave it for future until it actually becomes a problem for someone. :)
It's also possible to test these per-IP configurations with doveconf:
./doveconf -n -f lip=192.168.0.1 -f rip=10.1.2.3 -f service=imap