[Dovecot] Configuration file changes in CVS

Stuart Henderson stu at spacehopper.org
Thu Jul 10 14:06:39 EEST 2003


--On 10 July 2003 12:54 +0300 Timo Sirainen <tss at iki.fi> wrote:

> Actually I'm not really sure how things like INBOX should actually be
> defined. Or some other single mailbox file in the top level. INBOX
> shouldn't be shown as a separate namespace, but you might want it to
> have different settings.

Perhaps there could be one level of 'folder' containers allowed inside 
'namespace' in the config...

namespace {
  prefix =
  type = private
  separator = .
  location = maildir:~/
  folder {
    name = INBOX
    location = mbox:/var/mail/%u
    separator = /
  }
}

I think it may be something of a problem to expose different separators 
for different parts of the hierarchy... any clients which don't 
understand 'namespace' won't have a clue, and I suspect that some 
clients which do understand 'namespace' might not cope with different 
folder separators in different namespaces. So I think that 'separator' 
in namespace/folder config should refer to 'internal' namespace, and 
translate for the user. e.g. like 
<http://asg.web.cmu.edu/cyrus/download/imapd/altnamespace.html#unixhier
sep>

What does INBOX.foo do? What about INBOX/foo? Maybe there should be 
allow_subs = (yes|no) for folders (to set whether subfolders should be 
created with that 'style' or whether they should be created in the 
parent namespace).

If namespace configuration is being looked at now, it would probably 
make sense to ensure that it will be flexible enough to cope with as 
many future requirements as possible without change. I'm thinking of 
post-1.0 possiblities here, i.e. ACLs...I think that it might be worth 
examining any possible namespace config to see whether it's capable of 
implementing ACLs without big changes to the design.

Besides 'system' shared folders with ACLs, Cyrus has 'user' shared 
folders which it places in an 'other users' namespace (normally user.*) 
- this is *really* useful... Clients which know how to deal with ACLs 
don't require admin assistance to share a folder. e.g. login to an 
ACL-capable server with Mulberry (anonymous login to imap.cyrusoft.com 
will give some idea, though you can't change anything with that login), 
right-click a mail folder and choose 'Details' and you get an extra 
"access-control" tab with a GUI for adding users.

> This is getting dirty :)

You said it (-:


More information about the dovecot mailing list