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.
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 impleme
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, shou
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 comme
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 set
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
-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 optio
> 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 th
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
> > > }
> >
> > Th
> > 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 /1
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
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 d
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
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
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 prefe
-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 alwa
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 rul
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 thing
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 daemo
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 pos
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
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)?
--
Be
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
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 t
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
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 f
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
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 fi
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. Restr
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 initiall
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 initiall
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
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
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
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 wonderi
35 matches
Mail list logo