So while driving for several hours in my car recently and having nothing
else to do, I started thinking how they could be done.
I think the "public folders" configuration will stay as it is now.
Does
it really even need anything else? The problematic case is how the users
can share their mailboxes to other users. There are two problems related
to it:
1) How to get (quickly) a list of another user's mailboxes that I have
access to?
2) How to get quickly a list of all users who have mailboxes that I have
access to?
The 1) problem is easier to solve. Create a directory listing all the
mailboxes that are shared to at least someone (have ACLs set). It could
be configured like:
namespace shared {
# IMAP namespace prefix, %u expands to shared user
prefix = user/%u/
# Directory containing symlinks to user's all shared mailboxes
share_dir = ~/Maildir/shared
# Where to store indexes for other users' accessed mailboxes
index_dir = ~/Maildir/others-indexes
}
The ~/Maildir/shared directory could then contain symlinks to all the
shared mailboxes. The directory list could probably be in Maildir++
layout even though the symlinks would point to mboxes. This requires
adding code that can handle mixed maildir/mbox directories, but it'll
come anyway..
The 2) problem is more difficult. There are 3 choices:
a) Use a shared database file. lib-dict could be used for this, so the
database could be in SQL or in a berkeley db file. The downside to this
is that the file needs to be readable and writable to everyone, so if
users have shell access the users could break the file.
They dictionary would contain data in format
"<destination_user>/<sharing_user>" = 1 and
"<destination_group>/<sharing_user>" = 1, ie. the value
would be ignored
and only the existence of the keys would be important. Then iterating
through "<my_username>/*" and
"<all_my_groups>/*" would list the users
who probably have mailboxes where I have access to.
b) Use a directories with sticky bit set. Well, basically the same idea
as in a), except filesystem would be used. Actually perhaps this could
be made another lib-dict backend..
c) Brute force: Just assume everyone potentially have shared mailboxes.
Get the list of users by readdir()ing through /home (configurable).
I guess each of these could be made an option.. So something like:
namespace shared {
..
# a)
shared_dict = db:/var/lib/dovecot/shared-mailboxes.db
# b)
shared_dict = dir:/var/lib/dovecot/shared-mailboxes
# c)
shared_dict = bruteforce:/home
}
I'm currently also implementing a "mailbox list index", which
contains a
list of all the user's mailboxes and some useful metadata for them, such
as number of messages and so on. So that STATUS command wouldn't need to
open the mailbox index files if they haven't changed.
The mailbox list index updating is normally done when directory's mtime
has changed. For list of shared users that would also work in 2b) and
2c) cases, but for 2a) I'd either have to always sync everything or
alternatively add some sequence/<dest_user/group>=# value which is grown
for each update, and the syncing is done only when the sequence is
updated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20061024/7198d0c4/attachment.bin>
Hi Timo, I'm reading/thinking about the direction you're headed, but had a question... Here you say:> The ~/Maildir/shared directory could then contain symlinks to all the > shared mailboxes. The directory list could probably be in Maildir++ > layout even though the symlinks would point to mboxes.Why would the symlinks point to mboxes? Is it required for shared mailboxes to be in mbox format? If so, I'm confused - didn't you say that the support for Public Shared folders in maildir format should work? Or would this only apply to each Users Shared folders? If so, why? (please don't misunderstand, I'm not contradicting you, but I'm curious)... Lastly, are you contemplating adding support for Client-side control of the ACLs for the users Shared folders? I'm not sure about anyone else, but I don't give my users shell access, so they wouldn't be able set these up themselves... Thanks for sharing your thoughts out loud... -- Best regards, Charles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 24 Oct 2006, Timo Sirainen wrote:> I think the "public folders" configuration will stay as it is now. Does > it really even need anything else? The problematic case is how the users > can share their mailboxes to other users. There are two problems related > to it:> 1) How to get (quickly) a list of another user's mailboxes that I have > access to?You need this information for "LIST"? Just asking, it would help for large folder structures only, right? Otherwise, it adds yet another redundant stuff, one needs to maintain and probably fix, e.g. run a nightly job to verify the symlinks.> > 2) How to get quickly a list of all users who have mailboxes that I have > access to?Why do you need this information? Wouldn't it better to pass this information araund via, say, EMail? Then an user may SELECT a specific mailbox directly or can LIST an specific user. == What worries me more is the information in the following two pages: http://wiki.dovecot.org/ACL http://wiki.dovecot.org/SharedFolders For virtual users (with just one account for all users) there is no problem, but for real users ACLs superceed filesystem permissions. Dovecot would need to maintain the "dovecot-shared" files as well as mangle the permissions correctly. For global shared mailboxes one need to create a group giving all users get read / write permission, possibly narrowed down by the ACLs. But users with shell access can bypass the ACLs. When an user shares a mailbox to other users, either all these users must belong to one group or Dovecot need to create a group dynamically for them. Bye, - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBRT9nQi9SORjhbDpvAQKDgAf9EGtrFYcK84kAuDUiX/NovsnsxkALowRx OiedYNe5zXYhJnsss4PPxy6G2MtR6kEuP5z98r/HY0Koa2G/SmCjVGRmMnT1ZN0S Yf/igXU5HLSMllT3Kz4R3O5pwBFLDQieLufNrL3FCkbgCEqD/t3TGvBM/C+WKY3f pQyBzPbacUT4NqwlvLlRlC0UhgGHbpaCGdK6kTIsY6LH1xW90/W0wDbQNLSRZULP bgddCONV+jrbPFh/vZhH+Zjle9IWqKlKxUxSO+7R2ZYfrqQ+8AcRC8ElKZGDx8Ok 0CtZ3Ovi62qxbcqJrpk8I7fgvsL/Uw7VROZL5+pyKt5smGzl7FEL0g==sr1Q -----END PGP SIGNATURE-----
Timo Sirainen wrote:> I think the "public folders" configuration will stay as it is now. Does > it really even need anything else?One thing I notice is that if I read a message in my inbox and then move it to a public folder, it is marked as unread in the public folder. Ideally, it would be marked as read (for me, unread for others). I'm still on 1.0beta6 so forgive me if this has been changed in the RCs. Mark
On Tue, 2006-10-24 at 20:24 +0300, Timo Sirainen wrote:> I think the "public folders" configuration will stay as it is now. > Does > it really even need anything else?Hi Timo, As previously discussed on the list I'd love to see the ACL plug-in work with public folders and virtual users. Our mail server is 100% virtual users so we currently have free for all public folders, it's an accident waiting to happen... All we require is to be able to set permissions on the server, doesn't have to be user configurable. Gavin