dovecot - Apr 2008 - Public Namespace + ACLs + virtual users

g'day!

I'd just like to share my experience with public namespace and ACLs.

I know this has been discussed a number of times in the past, but there
were no definite answers.


dovecot version i'm using: 1.0.13


Got a public namespace setup in dovecot.conf as follows:

namespace public {
   separator = .
   prefix = Public_Folders.
   location = maildir:/home/vmail/domains/%
d/Public_Folders:CONTROL=/home/vmail/domains/%d/%
n/Public_Folders/support:INDEX=/home/vmail/domains/%d/%
n/Public_Folders/index
   hidden = no
}


In it's own right this works just fine and it's been in use for some
time now. But we need some control over who can access and delete
things.

So I had a go at configuring ACLs. I configured global ACLs, because as
far as I can tell, per directory ACLs seem to be ignored.

Once configured global ACLs work fine, except for 1 major issue; 
users cannot create new folders because ACLs do not get propagated (are
not applied to the subfolders).
If an user attempts to create a new (sub)folder, the folder is created
on the filesystem however email client throws an error and the folder is
inaccessible to the user as there is no ACL for it.


Any pointers how to get around this?

Has this been dealt with in v1.1?



Regards
Natko Muzina

On Wed, 23 Apr 2008, Fintec wrote:
> So I had a go at configuring ACLs. I configured global ACLs, because as
> far as I can tell, per directory ACLs seem to be ignored.
If global ACLs are working for you, you must have an "acl" line in
your
conf file's plugin section, probably somethine like:

plugin {
   acl = vfile:/some/directory
}

Try changing the acl line to "acl = vfile", without the colon or
anything
after it, and see if per-directory ACL's don't start working.

This is only a guess that seem likely to me based on my experience.  If 
this doesn't do the trick, you can elimnate a lot of guessing by sending 
the output of dovecot -n.