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
