[Dovecot] Configuration file changes in CVS

[Timo Sirainen]

On Thursday, Jul 10, 2003, at 15:06 Europe/Helsinki, Stuart Henderson 
wrote:

> 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 = /
>  }
> }

Yes, it has to be done something like this. namespace { .. } would map
into one real namespace reported by NAMESPACE command.

> 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.

Possibly. It may be required however if some namespace contains 
mailboxes containing the default separator, and vice versa. And 
separators can't be escaped.

Anyway, I think I won't allow using multiple different separators 
inside one namespace. That may be allowed by IMAP RFC, maybe even the 
NAMESPACE RFC but it's clearly against how it was thought to be used.

> So I think that 'separator' in namespace/folder config should refer to 
> 'internal' namespace, and translate for the user.

There's no point in specifying internal separator in most cases. Only 
possibly useful case would be if you wanted Maildir++ directories to 
use something else than '.', but that wouldn't be Maildir++ anymore and 
if you really wanted that, you could just recompile with some #define 
changed..

> 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).

I think it's better to always create them under the child mailbox. It's 
cleaner that way and less confusing. So if you had mbox INBOX while 
rest was Maildir, you'd have the INBOX marked \NoInferiors tag. 
Although I'm not sure if it should be done when there's another 
namespace that begins with INBOX.. Probably shouldn't, especially 
because not all clients understand namespaces. That makes it a bit more 
complicated..

> 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.

Yes.. But I can't really think of what problems the above configuration 
would have after adding ACLs. You could just add some acl = <value> 
entry there.

> 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...

Yes, this is a separate namespace type as well. I just didn't mention 
it yet since it's a whole different problem which is most likely 
post-1.0 feature.