dovecot - Feb 2009 - How many namespaces for several groups of shared mailboxes ?

Hello Timo,

let's say you want to implement several distinct groups of shared mailboxes
via
one (several) public namespace(s) with dovecot-1.1.x/Maildir. For instance,
team1, team2 and team3 work on different projects (project1, project2,
project3).

Obviously, as many public namespaces (#team1, #team2, #team3) would do the
trick, but then, any user (including users who don't belong to any above
team)
would 'see' useless non-selectionable folders #team*.

So my idea would be to create only one public namespace (#Public) into which
I'd
store directories team1, team2, team3, into which I'd put the needed shared
mailboxes. Something like

  /courriel/boites/public/team1/.shared-project1/
                         /team2/.shared-project2/
                         /team3/.shared-project3/


with something like

  namespace public {
    separator = /
    prefix = '#Public/'
    location = maildir:/courriel/boites/public
    inbox = no
    hidden = no
    list = yes
    subscriptions = yes
  }

I guess if unix right and ACL are set up correctly, other people would only see
non-selectionable '#Public'. 

The only problem is the subscription file : my understanding is that you have
only one subscription file per namespace.
Maybe unless you specify something like

  location = maildir:/courriel/boites/public:CONTROL=<some user dependent
location>

But wouldn't that induce another problem : such a CONTROL directive would
put
dovecot-uidlist and dovecot-keywords in the same user dependent location.

As I want to share the \Seen flag, I have to

  . put a dovecot-shared file
  . not specify INDEX (or at least, not to some user dependent location)

So I would end up with 

  . uid lists in some user dependant location (as a side effect of having
several subscriptions files)
  . but indexes shared

as uid is listed in index : wouldn't that be a problem ?

thanks

--
Thomas Hummel 	    | Institut Pasteur
<hummel at pasteur.fr> | P?le informatique - syst?mes et r?seau

On Wed, 2009-02-11 at 15:10 +0100, Thomas Hummel wrote:
>   /courriel/boites/public/team1/.shared-project1/
>                          /team2/.shared-project2/
>                          /team3/.shared-project3/
> 
> 
> with something like
> 
>   namespace public {
>     separator = /
>     prefix = '#Public/'
>     location = maildir:/courriel/boites/public
>     inbox = no
>     hidden = no
>     list = yes
>     subscriptions = yes
>   }
> 
> I guess if unix right and ACL are set up correctly, other people would only
see
> non-selectionable '#Public'. 
I don't really understand how that would work, since your location
points to the directory containing the team dirs so in maildir++ layout
it doesn't show up anything?

What you could do is override the location for each user separately. Or
set the location to e.g. ~/shared and have that to be a symlink to the
right team dir.
> The only problem is the subscription file : my understanding is that you
have
> only one subscription file per namespace.
Zero or one, yes. If you set subscriptions=no it'll use the parent
namespace's subscriptions file. So assuming you have a prefix=""
private
namespace, I'd think you would want the shared subscriptions there as
well.
> Maybe unless you specify something like
> 
>   location = maildir:/courriel/boites/public:CONTROL=<some user
dependent location>
> 
> But wouldn't that induce another problem : such a CONTROL directive
would put
> dovecot-uidlist and dovecot-keywords in the same user dependent location.
Yes, so that wouldn't work very well if any keywords are used.
> As I want to share the \Seen flag, I have to
> 
>   . put a dovecot-shared file
If you create dovecot-shared file, the \Seen flag won't be shared..
Currently the only way to change this is by modifying sources.
> So I would end up with 
> 
>   . uid lists in some user dependant location (as a side effect of having
several subscriptions files)
>   . but indexes shared
> 
> as uid is listed in index : wouldn't that be a problem ?
That would be a really broken setup since UIDs wouldn't match.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090220/cef23e5f/attachment-0002.bin>