[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