[Dovecot] v2.0 configuration parsing
Daniel L. Miller
dmiller at amfes.com
Mon Aug 10 22:29:20 EEST 2009
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
More information about the dovecot
mailing list