Re: [Dovecot] v2.0 configuration parsing

2009-08-10 Thread Felix Schueren 
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

2009-08-10 Thread Felix Schueren 
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] dbox benchmarks

2009-04-03 Thread Felix SchŸueren 

Timo Sirainen wrote:

On Apr 2, 2009, at 10:08 PM, Daniel L. Miller wrote:

I can see where large mailservers would benefit from significant write 
performance increases - but unless the server is being actively 
limited by the local delivery agent, what other performance benefits 
does this offer?


In particular, is there any increase in READ performance by using dbox?


Should be, since the files are larger there is most likely less 
fragmentation. But it's more difficult to benchmark read performance in 
a realistic way.



 Does it reduce memory consumption at all?


Maybe a bit, but that's probably irrelevant.

what's most relevant for us about dbox: Backups. We have lots of 
customers with huge maildirs, and Backups are taking forever (just 
having to fstat 100k entries takes a while, then all the individual 
stuff for all the new messages...). Go dbox! :)


Kind regards,

Felix

--
Felix Schüren
Head of NOC

--
Host Europe GmbH - http://www.hosteurope.de
Welserstraße 14 - D-51149 Köln - Germany
Telefon: (0800) 4 67 83 87 - Telefax: (01805) 66 32 33
HRB 28495 Amtsgericht Köln - UST ID DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller

<    1   2