[Dovecot] Shared mailbox plans

[Robert Schetterer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Timo Sirainen schrieb:
> ** 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.
Hi Timo,
for acl public folders with virtual domains, wouldnt it be a good idea
to have them in sql as backend?

- --
Mit freundlichen Gruessen
Best Regards

Robert Schetterer

https://www.schetterer.org
Munich/Bavaria/Germany
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGF4D7fGH2AvR16oERAi57AJ9iaNF3vEWr2wLXURuslUPteTZZPACffqE/
dw3GBitZB5FNXEkhIUSTAjI=
=QDH3
-----END PGP SIGNATURE-----