[Dovecot] Shared mailbox plans

[Timo Sirainen]

** Configuration **

namespace shared {
   prefix = user/%u/
   location = maildir:/home/%u/Maildir:INDEX=~/Maildir/shared-indexes
}

So the only difference to how it's configured now is that %u is  
expanded to whatever user whose mailboxes we're accessing. ACL plugin  
then uses that user as the owner in the namespace's mailbox owner.  
Since the default ACL is to not give any access to non-owners, the  
mailboxes without dovecot-acl files will be invisible.

If ACL plugin isn't loaded, I suppose the mailboxes can be accessed  
if the process has filesystem permissions to access them.

** ACL vfile speedups **

Currently it stat() the dovecot-acl file a bit too often. It doesn't  
do it more than once a second, but there's really no need to do it  
even that often. I guess it could be changed to be configurable with  
default being something like 5 minutes.

Create a new dovecot-acl-list file which lists all the mailboxes  
which have dovecot-acl file with "l" right (visible in mailbox list)  
to any non-owner. It could be in "<timestamp> <mailbox name>" format.  
This allows other users to quickly get a list of mailboxes that are  
potentially visible to them. They still need to read the dovecot-acl  
file from the mailbox before knowing for sure.

If the dovecot-acl-list file doesn't exist or if at any time any  
timestamp doesn't match dovecot-acl file's current mtime, the file is  
rebuilt by looking into all mailboxes' dovecot-acl files (if the  
reading user has write permissions to the directory, otherwise it  
just keeps it in memory). Whenever Dovecot modifies dovecot-acl file,  
it also updates the dovecot-acl-list file. This means that the file  
can contain stale data only if a new dovecot-acl file is created  
without updating dovecot-acl-list file. Even that will be fixed the  
next time the owner does a LIST (or select the mailbox, or anything  
that causes its dovecot-acl file to be stated), which causes ACL  
plugin to notice the desync.

There exist also global ACL files. These need to be included in the  
dovecot-acl-list file as well. The only issue with them is that user  
doesn't necessarily have a mailbox even though the global ACL file  
exists. So these need to be marked somehow in the dovecot-acl-list  
file as non-existing mailboxes. Then if user creates a mailbox with  
such name, the mark is removed. Deleting the mailbox puts the mark back.

After the visible mailbox list has been figured out once, only the  
dovecot-acl-list file needs to be stat()ed once in a while instead of  
all the mailboxes' dovecot-acl files.

** User list **

The next problem is how to quickly get a list of users whose  
mailboxes are visible to ourself so they can be included in mailbox  
list. I couldn't figure out anything new and great for this, so the  
options are the same as in http://dovecot.org/list/dovecot/2006- 
October/017082.html

Although for dict backend I could make it a bit more secure.  
Currently dict has "private" and "shared read-write" options to store  
the data with. The shared users list could be done with "shared read- 
only".

** Virtual domains **

ACL plugin could support virtual "group=@domain" to give access to  
usernames ending with @domain. Or perhaps the group could support  
wildcards? "group=*@domain"? That way it wouldn't be required to have  
@ really in the username.

Anyway, I think "anyone" should then be aliased to "group=*@domain".  
If there are multiple virtual domains and you let the users  
manipulate the ACLs themselves, I'd think they want anyone to mean  
anyone within my domain (my organization) rather than really anyone  
who just happens to be using the same server.

I think it would also be annoying if anyone could really force their  
own mailboxes to be visible to a lot of people. That could be used  
for spamming as well..

If administrator wants to have global mailboxes that really are  
visible to all domains, they could be done with public namespaces  
(not shared).

** Quota **

This is kind of problematic. The behavior depends entirely on quota  
backend:

  - Filesystem quota of course tracks the quota based on the file's  
owner

  - Maildir++ quota counts the quota for the user whose maildir the  
shared mailbox exists in. This means it also requires filesystem  
level access to maildirsize file, otherwise the quota updating  
happens sometimes later when the quota is recalculated.

  - Dict quota.. I think it'll need a new path for each shared  
mailbox, which is modifiable by any user. So while your own quota  
would exist in private/quota/storage, the shared mailboxes' quota  
would exist in shared/quota/storage. This means that the dict quota  
needs to be able to know what mailboxes the current user has shared.  
It also gets a bit tricky to update the quota if mailbox is unshared.  
The quota could be tracked individually for each mailbox also, but  
I'm not sure if that's such a great idea either.

Perhaps a new quota backend could be implemented to make all this  
easier. The mail sizes could be tracked in index file, so getting the  
size of a mailbox could be done simply by reading the value from the  
index file's header. With mailbox list indexes (in CVS HEAD) they'd  
all be listed in a single mailbox.list.index file, which would make  
summing them up really fast. This would require that users don't use  
private index files for shared mailboxes though. But if the users  
don't have shell access the shared index files are probably a good  
idea anyway (at least from performance point of view).

** Symlink shares **

Currently the only way to implement shared mailboxes among users is  
for administrator to create symlinks. This will be possible in future  
too with a configuration like:

namespace shared {
   prefix = Shared/
   location = maildir:~/Maildir/shared-symlinks:INDEX=~/Maildir/ 
shared-indexes
}

The "owner" ACL won't match anyone. So it'll work exactly as it does  
now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20070407/5718754e/attachment.pgp