Thomas Hummel
2009-Feb-11 14:10 UTC
[Dovecot] 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
Timo Sirainen
2009-Feb-20 23:09 UTC
[Dovecot] How many namespaces for several groups of shared mailboxes ?
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 fileIf 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>
Seemingly Similar Threads
- Optim function with meta parameters
- Antw.: Word/Excel documents cannot be saved after Samba Upgrade
- BUG: cannot move messages to root mailfolder in namespace "There can be only one namespace with inbox=yes"
- automount, samba, desktop.ini issues
- BUG: cannot move messages to root mailfolder in namespace "There can be only one namespace with inbox=yes"