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 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?
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
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
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
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
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 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, 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
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
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
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
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
-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
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
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
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
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
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
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
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.
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
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
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
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
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
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, 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)?
--
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
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
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
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
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
-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
34 matches
Mail list logo
