Timo Sirainen wrote:
On Mon, 2009-08-10 at 12:09 -0700, Daniel L. Miller wrote:
If at all possible, I would much rather see an error thrown than choosing which one to accept. To me, having Dovecot tolerate broken configurations is less desirable than giving clear feedback for the user to fix it. Anything from:
"foo" is defined more than once overlapping ip declarations "remote_ip" declaration in protocol "imap" conflicts with "remote_ip" declaration in protocol "all"
It's not necessarily a broken configuration. For example you could have:
disable_plaintext_auth = yes # default also remote_ip 192.168.0.0/16 { # allow plaintext auth from intranet disable_plaintext_auth = no }
That's an ok configuration, right? But then again, maybe one of those IPs is a proxy to outside world and you don't want plaintext auth from there:
remote_ip 192.168.123.44 { disable_plaintext_auth = yes }
But I guess if there truly are some conflicts it could warn about them .. although that might be more work than it's worth. :)
Well - if those are not broken configs, then I guess I misunderstood the question. I would expect the most restrictive test to govern, so:
remote_ip 192.168.0.0/16 { # allow plaintext auth from intranet disable_plaintext_auth = no }
remote_ip 192.168.10.0/8 { # allow plaintext auth from intranet disable_plaintext_auth = yes }
remote_ip 192.168.0.1 { # allow plaintext auth from intranet disable_plaintext_auth = no }
connecting from 192.168.0.1 should result in disable_plaintext_auth = no.
-- Daniel-5276