I'm wondering a bit how these should work. Comments welcome. In v2.2 the recommended way to enable private flags for shared mailboxes is to create private indexes with :INDEXPVT=<path>. This creates dovecot.index.pvt[.log] files which only contain message UIDs and flags. The indexes are updated somewhat lazily by updating them whenever user has the shared mailbox opened and it gets synced. 1. What would be a good place to configure which flags are shared and which are private? Currently it forces \Seen flag to be private and others not. With Maildir I used to have the idea of configuring these in dovecot-shared file, but that's a rather annoying extra file. Then again it could be cached into dovecot.index. Another possibility would be in dovecot-acl file, but public mailboxes might be enabled without ACL plugin. Mailbox attributes (for URLAUTH and for future METADATA) also exist in v2.2, but they require configuring a dict for them, which isn't very efficient either to read every time a mailbox is accessed. Mailbox's admin user should be able to do this somehow via IMAP protocol also. METADATA would pretty much be required for that I guess. 2. Private flags aren't currently inherited from the primary (shared) flags. With user-shared mailboxes this is good, because the owner doesn't have private indexes for the mailboxes, so when owner reads a mail it gets a \Seen flag in the primary index. If that mailbox was shared to someone else, the \Seen flag shouldn't be set. But this also means that for truly shared (public) mailboxes that have no owner you can't set initial flags with Sieve's addflag command (e.g. \Seen flag to high-scored mails in Spam). I guess it could be possible to change this so that the inheritance is done for public namespaces but not for shared namespaces, but is that really a good idea either?.. 3. Currently COPY/APPEND ignore any private flags (which also means dsync won't set them always). Fixing this would require remembering these flags, committing the save to primary index, syncing the private index to get the new mails added there, then updating their flags (or doing it directly at sync stage with some kludging code). To avoid race conditions the private index would need to be locked before committing the save. I guess this is doable.. 4. Private keywords aren't supported. I guess not much worse than system flags, but more code complexity. Wonder if anyone would care about them.
At 8PM +0200 on 16/02/13 you (Timo Sirainen) wrote:> > 1. What would be a good place to configure which flags are shared and > which are private? [...] Another possibility would > be in dovecot-acl file, but public mailboxes might be enabled without > ACL plugin.[...]> > 4. Private keywords aren't supported. I guess not much worse than > system flags, but more code complexity. Wonder if anyone would care > about them.Does this mean non-owners can't set keywords, or that keywords they set are set for everyone? I can see the latter being irritating, since some clients (like Thunderbird) tend to set keywords without being asked to. Denying 'w' would presumably prevent this, but that rather reduces the point of having shared flags other than \Seen in the first place. I think ideally one would want an extension to ACL, which supports a per-flag (or keyword) per-mailbox per-user permission which can be either no access, read, write shared, or write private. I don't think this can sensibly be stuffed into the existing ACL extension (the only reasonable place to put the flag name is as part of the user identifier, which is confusing and crude), so this would mean a new GETFLAGACL/ SETFLAGACL/MYFLAGRIGHTS IMAP extension. Unless you think this can be sensibly set via METADATA (I'm not familiar with that extension, so I don't know whether using it for access control would be reasonable)? Personally I don't think it's worth worrying about the case of shared mailboxes without ACL. Ben
On Sat, 2013-02-16 at 20:19 +0200, Timo Sirainen wrote:> I'm wondering a bit how these should work. Comments welcome.Well, I guess:> In v2.2 the recommended way to enable private flags for shared mailboxes is to create private indexes with :INDEXPVT=<path>. This creates dovecot.index.pvt[.log] files which only contain message UIDs and flags. The indexes are updated somewhat lazily by updating them whenever user has the shared mailbox opened and it gets synced. > > 1. What would be a good place to configure which flags are shared and which are private? Currently it forces \Seen flag to be private and others not. With Maildir I used to have the idea of configuring these in dovecot-shared file, but that's a rather annoying extra file. Then again it could be cached into dovecot.index. Another possibility would be in dovecot-acl file, but public mailboxes might be enabled without ACL plugin. Mailbox attributes (for URLAUTH and for future METADATA) also exist in v2.2, but they require configuring a dict for them, which isn't very efficient either to read every time a mailbox is accessed. Mailbox's admin user should be able to do this somehow via IMAP protocol also. METADATA would pretty much be required for that I guess.Probably won't happen before v2.3.> 2. Private flags aren't currently inherited from the primary (shared) flags. With user-shared mailboxes this is good, because the owner doesn't have private indexes for the mailboxes, so when owner reads a mail it gets a \Seen flag in the primary index. If that mailbox was shared to someone else, the \Seen flag shouldn't be set. But this also means that for truly shared (public) mailboxes that have no owner you can't set initial flags with Sieve's addflag command (e.g. \Seen flag to high-scored mails in Spam). I guess it could be possible to change this so that the inheritance is done for public namespaces but not for shared namespaces, but is that really a good idea either?..Initial private flags are copied now from shared flags for mailboxes in public namespaces, but not elsewhere.> 3. Currently COPY/APPEND ignore any private flags (which also means dsync won't set them always). Fixing this would require remembering these flags, committing the save to primary index, syncing the private index to get the new mails added there, then updating their flags (or doing it directly at sync stage with some kludging code). To avoid race conditions the private index would need to be locked before committing the save. I guess this is doable..Fixed.> 4. Private keywords aren't supported. I guess not much worse than system flags, but more code complexity. Wonder if anyone would care about them.Private \Seen flag is good enough for now.