Re: [Dovecot] v2.0 configuration parsing
On 9/3/2009 4:43 PM, Timo Sirainen wrote: The difference between dovecot -n and postconf -n is that dovecot -n doesn't show settings that have been explicitly set to defaults. doveconf -N now does that, while doveconf -n works like before. wow - Timo, you are amazing, no doubt about it. Thanks... :) -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On Fri, 2009-08-14 at 06:05 -0400, Charles Marcus wrote: On 8/13/2009, Timo Sirainen (t...@iki.fi) wrote: The difference between dovecot -n and postconf -n is that dovecot -n doesn't show settings that have been explicitly set to defaults. Ahhh, I hadn't noticed that... So, should it? doveconf -N now does that, while doveconf -n works like before. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
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.:
1) 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
}
2) 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
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
On 8/13/2009, Timo Sirainen (t...@iki.fi) wrote: The difference between dovecot -n and postconf -n is that dovecot -n doesn't show settings that have been explicitly set to defaults. Ahhh, I hadn't noticed that... So, should it? To me, it kind of makes sense for defaults to be displayed commented in the config file right after the explanatory text - for documentation purposes, ie to show what the default setting is, and to serve as an example of proper syntax - and then anything that is explicitly set should show in -n output, whether it is explicitly set to the default setting or not... But its no big deal, that just how things would be if I were king... ;) -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On Tue, 2009-08-11 at 07:16 -0400, Charles Marcus wrote: I like that I can use postconf -d (show default settings - and this is why I'd like to have a doveconf -d, as well as doveconf -n), to see if I have specifically set any defaults, and if I did, delete/comment them. This limits the settings returned by postconf -n, which makes it easier to read. I'd like dovecot to have the same capability. The difference between dovecot -n and postconf -n is that dovecot -n doesn't show settings that have been explicitly set to defaults. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
On Monday 10 August 2009 19:57:53 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 generally prefer the most specific rule wins. If that is not the case, it
should not be possible to specify the same configuration within containers of
different scope. It is not intuitive to have a value in a restricted scope
and in a more general scope, and there are situations when the general value
is used even though the specifiv scope
The most specific kind of makes more sense initially,
but then you start wondering how to handle e.g.:
1) 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
}
This one is easy. It should be foo in any case :-)
Protocol sections that are more specific are an existing and coarse-granular
concept, and AFAIk now it doesn't matter whether the protocol section is
before or after the general setting. This concept should in any case be
retained.
2) 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
}
}
Any thoughts?
Perhaps this should be invalid.
Rainer
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Noel Butler (noel.but...@ausics.net) wrote: I think first rule match is best approach, as someone else pointed out, its how many things that most people here would work with daily work, be it a server daemon configuration, iptables, or Cisco routers. The only exceptions that I can think of immediately is Apache, ircu, and DNews where last (entered in order) matching rule wins. Don't forget postfix - its 'last rule wins' too, and is why I vote for last rule wins for dovecot, or, worst case, if there is more than one give an error, or at least a warning. -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Noel Butler (noel.but...@ausics.net) wrote: Can you give me some other examples than firewalls or routing? Postfix, Eh?? Not on my box. If I add a duplicate setting at the bottom, that setting overrides any previous setting. -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Timo Sirainen (t...@iki.fi) wrote: (I'm also wondering about if it should be the first rule. Somehow to me it comes more naturally that last settings always override previous settings. For config files, I agree. If we really want to make first settings come first, then the default settings must be at the bottom of dovecot.conf, or they'd need some exception.) Or just have the default settings there as an example, but commented out. Have an explanation at the top of the config file that if you only need the default settings, they do not need to be uncommented, and that the last setting wins (or will cause a warning or error, or whatever you decide). I like that I can use postconf -d (show default settings - and this is why I'd like to have a doveconf -d, as well as doveconf -n), to see if I have specifically set any defaults, and if I did, delete/comment them. This limits the settings returned by postconf -n, which makes it easier to read. I'd like dovecot to have the same capability. When I did this, I cut the ouput down from 80 lines to less than 40. -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On 8/11/2009, Charles Marcus (cmar...@media-brokers.com) wrote: Eh?? Not on my box. If I add a duplicate setting at the bottom, that setting overrides any previous setting. In fact, this is one of the reasons postconf -n output is necessary when asking for help on the list... more than once I have seen someone come back and say 'oh, yeah, I forgot I'd set that at the bottom when I wast testing blah blah'. -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
1) 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
}
This one is easy. It should be foo in any case :-)
Why? /24 is more specific than /16, but protocol imap is more specific than
(implicit) protocol any. I assume this is why Timo included this example.
Gr.
Matthijs
signature.asc
Description: Digital signature
Re: [Dovecot] v2.0 configuration parsing
On Tuesday 11 August 2009 15:32:42 Matthijs Kooijman wrote:
1) 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
}
This one is easy. It should be foo in any case :-)
Why? /24 is more specific than /16, but protocol imap is more specific than
(implicit) protocol any. I assume this is why Timo included this example.
You are right, and I left out half of my thoughts. I think there should be
only a coarse grained concept of more specific rules - e.g. a protocol
section is more specific than general config, and a local or remote IP
restriction is more specific than a protocol section. I think that the values
of these context selectors should not define more specific. Within one of
these levels, either conflicting settings should be invalid, or maybe better
yet, a last wins rule should apply.
Gr.
Matthijs
Rainer
Re: [Dovecot] v2.0 configuration parsing
You are right, and I left out half of my thoughts. I think there should be
only a coarse grained concept of more specific rules - e.g. a protocol
section is more specific than general config, and a local or remote IP
restriction is more specific than a protocol section. I think that the values
of these context selectors should not define more specific. Within one of
these levels, either conflicting settings should be invalid,
But that would prevent the following (intuitive) config from working:
remote_ip 192.168.0.0/16 {
foo = bar
}
remote_ip 192.168.10.0/24 {
foo = baz
}
This would need some kind of condition like
remote_ip 192.168.0.0/16 !192.168.10.0/24 {..}
or something.
or maybe better yet, a last wins rule should apply.
Or you would indeed use this, which makes the above config easy to write
wrongly. (If you swap the conditions). You might still detect that a later
directive completely overrides a previous setting in all cases and issue a
warning, but this is probably hard to do in general.
An alternative that just occured to me is to always do these kind of
exceptions in a nested way. The above would then become:
remote_ip 192.168.0.0/16 {
foo = bar
remote_ip 192.168.10.0/24 {
foo = baz
}
}
which is probably even more intuitive than my first example. This way, the
user explicitly specifies which directives can override other directives. This
is comparable to having a fixed order of protocol, remote_ip, local_ip
that was proposed somewhere in this thread, but allows the user to pick the
order.
This does mean that you might need explicit else, or other clauses, since
you cannot mix different selectors on the same level of the hierarchy.
protocol imap {
remote_ip 192.168.0.0/24 {
foo = bar
}
}
protocol other
remote_ip = 192.168.10.0/16 {
foo = baz
}
}
A big downside of this approach is probably that you can't easily add a rule
for some remote_ip condition regardless of the protocol to the last example,
since that should then be specified in both protocol blocks... So, not sure if
this is really a useful suggestion, but perhaps thinking about it will help
:-)
Gr.
Matthijs
signature.asc
Description: Digital signature
Re: [Dovecot] v2.0 configuration parsing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 10 Aug 2009, Timo Sirainen wrote: I'm trying to figure out how exactly v2.0 should be parsing IMO, most specific won't work as you pointed out several times, because Dovecot cannot know, which precendence the zillion configuration options and conditionals have in the particular setup. In my view, first match is good, if one needs quick processing time and can cut, once the match is found. E.g. in firewalls and routers. Or when the options are not _conditionally_ assigned, e.g. in sendmail cf, you do not have no way to have a config option _not_ apply. Most conf files/system I know, that split between common (or default) setting and specific overrides work in last match. They bundle the default settings on top and specify the overrides below, just like a program, as already pointed out. Moreover, because most programs parse the config file til its end anyway. It is more work to debug problems, but in my eyes the conf files look cleaner. There are a few, where you can fix a setting, so it cannot be overwritten later, but mostly because first the system conf file is parsed and should be able to fix some settings against user override. Maybe a dovecot debug mode can issue the line number when a setting is assigned. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSoGFynWSIuGy1ktrAQJY3Qf/Tv96bzBg4yd4fOuY/rplpf7ap3DJv//K geDA8WWHuzU4J505DmBi0AxvmfZ6ZHFnII0xGnatK9qxaaWDTceqdRJlZWdf25XL Hf52ff4xVOgQXpoqvh0zT8VxM4q9Qe7mH2g4VTz0eKbvVP0qFaHBAv66qa1czgGP 9Xj27YrmE3FKiurCkVCwVzGFQM4akTs+qD3VvBy3sTyoLB3XenzS6e4EXjsbQAQe McaUUL/nJKtKwXyN7aH3lKZaFe3ECsb1SZWtTxQ4GAEuwPeawWIrK3r1S1ykfYUV ZQERdMVWgc1FsG5IdTTYcq5DgHSWEotRcN92Aw7v9i20yaTw1wKSEg== =b+sT -END PGP SIGNATURE-
Re: [Dovecot] v2.0 configuration parsing
I would suppose that partly overlapping rules are most often a sign of a configuration error. So how about 1) most specific rule wins (or last rule wins, forcing more specific rules to appear further down the file) 2) partly overlapping flag an error, except for 3) using != (or whatever) instead of = surpresses the error and makes the last rule win.
[Dovecot] v2.0 configuration parsing
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. The most specific kind of makes more sense initially,
but then you start wondering how to handle e.g.:
1) 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
}
2) 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
}
}
Any thoughts?
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
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. The most specific kind of makes more sense initially,
but then you start wondering how to handle e.g.:
1) 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
}
2) 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
}
}
Any thoughts?
I think the easiest scheme to keep in my brain would be to evaluate the
blocks, in order, as if they were branches in code. Fooling around with
an arbitrary order of evaluation/specificity would be a recipe for
disaster (see, for example, any CSS engine).
So, something like,
protocol imap {
remote_ip 192.168.0.0/16 {
foo = foo
}
}
would translate to,
if (protocol == imap) {
if (remote_ip matches 192.168.0.0/16) {
foo = foo
}
}
and then later,
remote_ip 192.168.0.0/24 {
foo = bar
}
would set the value of 'foo' to 'bar', since it would evaluate in a
similar fashion, and comes later in the config file.
It's easy to explain, easy to implement, and easy to debug. Ultimately,
the users are going to have to understand how it works in order to
configure Dovecot properly. Put the most general rules first, and then
override them is a practice with which most of us are already familiar.
Re: [Dovecot] v2.0 configuration parsing
Hi Timo,
What's your thought on the 'precedence order' (hope it make sense),
on protocol, remote_ip, local_ip?
From your sample 1, it would read equals (to most technical people) to
protocol imap
{
remote_ip 192.168.0.0/16
{
foo = foo
}
}
protocol ALL
{
remote_ip 192.168.0.0/24
{
foo = bar
}
}
If follow this syntax, sample 1's answer would be foo = foo, assuming
specific rules overwrite general rules, and assuming protocol is the
first order.
Sample 2 is tough, that's why I asked what's your thought on
precedence order. Restricting syntax to only remote before local (or
vice versa) should resolve it.
Joseph
On 10-Aug-09, at 1:57 PM, 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. The most specific kind of makes more sense
initially,
but then you start wondering how to handle e.g.:
1) 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
}
2) 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
}
}
Any thoughts?
Re: [Dovecot] v2.0 configuration parsing
On Aug 10, 2009, at 11:57 AM, 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. The most specific kind of makes more sense
initially,
but then you start wondering how to handle e.g.:
1) 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
}
2) 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
}
}
Any thoughts?
Figure out that they intersect and return an error!
Aria Stewart
aredri...@nbtsc.org
Re: [Dovecot] v2.0 configuration parsing
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. The most specific kind of makes more sense initially,
but then you start wondering how to handle e.g.:
1) 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
}
make it
protocols {
imap {
remote_ip x/16 {
foo = foo
}
}
all {
remote_ip x/24 {
foo = bar
}
}
}
2) 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
}
}
I'd strongly suggest to use the same approach as firewalls (or exim):
first match wins. I love exim because I can configure it much like my
firewalls routers, and the fall through until something matches
syntax that most firewalls/ACLs use is well-understood flexible.
Kind regards,
Felix
--
Felix Schüren
Head of Network
---
Host Europe GmbH - http://www.hosteurope.de
Welserstraße 14 - 51149 Köln - Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller
(*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 14:33 -0400, Joseph Yee wrote:
Hi Timo,
What's your thought on the 'precedence order' (hope it make sense),
on protocol, remote_ip, local_ip?
I'm not sure if there is one.
Sample 2 is tough, that's why I asked what's your thought on
precedence order. Restricting syntax to only remote before local (or
vice versa) should resolve it.
Actually I don't think it would really solve much either.
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
}
}
You could write this as:
local_ip 192.168.0.1 {
remote_ip 10.1.2.0/24 {
foo = foo
}
}
local_ip 192.168.0.0/24 {
remote_ip 10.1.2.3 {
foo = bar
}
}
You'd still have to decide if local_ip is more important than remote_ip,
or if it should just be done in order and it should always use either
first or last.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 20:47 +0200, Felix Schueren wrote:
make it
protocols {
imap {
remote_ip x/16 {
foo = foo
}
}
all {
remote_ip x/24 {
foo = bar
}
}
}
That's just a syntax change. The question is still about if it should
match the first one or the most specific one.
I'd strongly suggest to use the same approach as firewalls (or exim):
first match wins. I love exim because I can configure it much like my
firewalls routers, and the fall through until something matches
syntax that most firewalls/ACLs use is well-understood flexible.
Yeah, I'm beginning to think something like this would be good, with
perhaps some restrictions in how the configuration blocks could be used.
But is it better to use the first or the last match?..
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
Timo Sirainen wrote:
On Mon, 2009-08-10 at 20:47 +0200, Felix Schueren wrote:
make it
protocols {
imap {
remote_ip x/16 {
foo = foo
}
}
all {
remote_ip x/24 {
foo = bar
}
}
}
That's just a syntax change. The question is still about if it should
match the first one or the most specific one.
I'd strongly suggest to use the same approach as firewalls (or exim):
first match wins. I love exim because I can configure it much like my
firewalls routers, and the fall through until something matches
syntax that most firewalls/ACLs use is well-understood flexible.
Yeah, I'm beginning to think something like this would be good, with
perhaps some restrictions in how the configuration blocks could be used.
But is it better to use the first or the last match?..
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
I suppose if you really want to tolerate the brokenness - at least
include the error as a logged warning.
--
Daniel
Re: [Dovecot] v2.0 configuration parsing
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. :)
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
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
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Timo Sirainen (t...@iki.fi) wrote: Yeah, I'm beginning to think something like this would be good, with perhaps some restrictions in how the configuration blocks could be used. But is it better to use the first or the last match? For a filter (like a firewall), it makes sense to have the first match win. For config stuff, I think the LAST should win... at least, thats how postfix works... Or maybe even better, if you have the same setting defined twice, you could also detect this and issue a warning, like you do now for fd's set too low... -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Michael Orlitzky (mich...@orlitzky.com) wrote: It's easy to explain, easy to implement, and easy to debug. Ultimately, the users are going to have to understand how it works in order to configure Dovecot properly. Put the most general rules first, and then override them is a practice with which most of us are already familiar. One thing I'd like is to sort the simple one line foo = bar settings first (before the blocks) - in alphabetcial order. If it makes more sense to keep the blocks in a specific order, thats fine, otherwise you could alphabetize them too. Right now, if you have a lot of settings, finding any particular setting (ie, when troubleshooting) is much more difficult than it should be, especially for someone new to dovecot. -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Charles Marcus (cmar...@media-brokers.com) wrote: One thing I'd like is to sort the simple one line foo = bar settings first (before the blocks) - in alphabetcial order. Of course, I meant with respect to doveconf -n output... or did you decide yet on the new command(s)? -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
Daniel L. Miller wrote:
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.
I agree - however, it makes the config harder to read, and you pretty
much need something like dovecotctl -acl -dump or an equivalent to
netstat -r or iptables -L to display them in the correct order if the
ruleset becomes complex. By using a first-match wins syntax, you make
the actual config file much simpler to read, as it maps to the running
process.
kind regards,
Felix
--
Felix Schüren
Head of Network
---
Host Europe GmbH - http://www.hosteurope.de
Welserstraße 14 - 51149 Köln - Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller
(*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend
Re: [Dovecot] v2.0 configuration parsing
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 think it's possible to do both:
Use the most specific rule, but if it's also not the first rule, it's a
broken configuration and it'll fail. If there are ambiguity in
specificity, it's also an error.
(I'm also wondering about if it should be the first rule. Somehow to me
it comes more naturally that last settings always override previous
settings. If we really want to make first settings come first, then the
default settings must be at the bottom of dovecot.conf, or they'd need
some exception.)
Require the nesting to be in order:
local_ip {
remote_ip {
protocol {}
}
}
Any of the levels could be dropped out, but the ordering couldn't be
switched. Then we'll basically require that more specific blocks need to
be before less specific blocks, or the configuration reading will fail.
(Or vice versa? It somehow seems more natural to me..) The block
specificity is determined by the nesting order.
1) Simple example:
# allow plaintext auth from intranet, except from .123.1
remote_ip 192.168.123.1 {
disable_plaintext_auth = yes
}
remote_ip 192.168.0.0/16 {
disable_plaintext_auth = no
}
disable_plaintext_auth = yes
If the remote_ip blocks were switched, it would give an error.
2) More complex example:
Client connecting 192.168.0.1 - 10.1.2.3.
# this first match is used
local_ip 192.168.0.1/31 {
remote_ip 10.1.2.0/24 {
foo = foo
}
}
# ok, exact match (handle the same as duplicate settings in root,
# maybe optionally give a warning about them)
local_ip 192.168.0.1/31 {
remote_ip 10.1.2.0/24 {
foo = foo2
}
}
# error, local_ip more specific
local_ip 192.168.0.1 {
foo = xx
}
# ok, local_ip less specific, remote_ip less specific
local_ip 192.168.0.0/16 {
remote_ip 10.1.2.0/23 {
foo = bar
}
}
# error, remote_ip more or equal specific
local_ip 192.168.0.0/16 {
remote_ip 10.1.2.3 {
foo = baz1
}
remote_ip 10.1.2.0/24 {
foo = baz2
}
}
# error, protocol more specific
local_ip 192.168.0.0/16 {
protocol imap {
foo = x
}
}
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 17:59 -0400, Timo Sirainen wrote: (I'm also wondering about if it should be the first rule. Somehow to me I think first rule match is best approach, as someone else pointed out, its how many things that most people here would work with daily work, be it a server daemon configuration, iptables, or Cisco routers. The only exceptions that I can think of immediately is Apache, ircu, and DNews where last (entered in order) matching rule wins. Noel
Re: [Dovecot] v2.0 configuration parsing
On Tue, 2009-08-11 at 09:20 +1000, Noel Butler wrote: On Mon, 2009-08-10 at 17:59 -0400, Timo Sirainen wrote: (I'm also wondering about if it should be the first rule. Somehow to me I think first rule match is best approach, as someone else pointed out, its how many things that most people here would work with daily work, be it a server daemon configuration, iptables, or Cisco routers. Can you give me some other examples than firewalls or routing? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 19:28 -0400, Timo Sirainen wrote: On Tue, 2009-08-11 at 09:20 +1000, Noel Butler wrote: On Mon, 2009-08-10 at 17:59 -0400, Timo Sirainen wrote: (I'm also wondering about if it should be the first rule. Somehow to me I think first rule match is best approach, as someone else pointed out, its how many things that most people here would work with daily work, be it a server daemon configuration, iptables, or Cisco routers. Can you give me some other examples than firewalls or routing? Postfix, (and as mentioned by another poster Exim never used it myself tho), and I think Sendmail as well, MailScanner, and I was wrong about Apache, first vhost matches (I just threw an alias into a 3 vhosts and it went to the first matching vhost) Noel
Re: [Dovecot] v2.0 configuration parsing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I completely agree with Michael's opinion.
Patrick.
On 2009-08-11 02:22, Michael Orlitzky wrote:
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. The most specific kind of makes more sense initially,
but then you start wondering how to handle e.g.:
[...]
I think the easiest scheme to keep in my brain would be to evaluate the
blocks, in order, as if they were branches in code. Fooling around with
an arbitrary order of evaluation/specificity would be a recipe for
disaster (see, for example, any CSS engine).
So, something like,
protocol imap {
remote_ip 192.168.0.0/16 {
foo = foo
}
}
would translate to,
if (protocol == imap) {
if (remote_ip matches 192.168.0.0/16) {
foo = foo
}
}
and then later,
remote_ip 192.168.0.0/24 {
foo = bar
}
would set the value of 'foo' to 'bar', since it would evaluate in a
similar fashion, and comes later in the config file.
It's easy to explain, easy to implement, and easy to debug. Ultimately,
the users are going to have to understand how it works in order to
configure Dovecot properly. Put the most general rules first, and then
override them is a practice with which most of us are already familiar.
- --
STAR Software (Shanghai) Co., Ltd. http://www.star-group.net/
Phone:+86 (21) 3462 7688 x 826 Fax: +86 (21) 3462 7779
PGP key: E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc
Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkqA5IEACgkQ7yMg/OiDoAWaiQCgk1S6lu6JQTcg5VXzwzJxrjCG
AXcAoLD2xvbfFoMUrSW+3JrC+PA7c8Fz
=jChR
-END PGP SIGNATURE-
