While I can appreciate the feature you are trying to implement, the proposed implementation is.. well... limited.
For instace how do you give access to sfLocationA to mbUserG? I'm envisioning a use for this where Shared Folders are "mailing lists" for projects at a company. You have a set of people, and each person can subscirbe to the Shared Folder of the project they are working on. I use the term project loosely as it represents any group a person might be involved in like their department, or the emeergency response team. In your proposal, the nature of the Shared Folders being added and removed often as projects come and go is extraordinarily cumbersome becuase users mailboxes have to be continuously moved around. Further, how do you have a manager for more than one project without giving all members of those projects access to the other shared folders. What do you do if you have UserA on ProjectX and ProjectY, while UserB is on ProjectX and ProjectZ. In reality, the current architecture seems to most closely resemble the real world. You have a set of users, who have access to a separate set of Bulletin Boards. You have control over which users have what level of access to each of Bulletin Boards and while doing an "lm" ends up being very unhelpful because of the large list of mailboxes that come back, it is the most logical and straight forward way to achieve the desired feature set. One useful thing I am gleaning from your post is a more conrete way to implement virtual domains. Currently Cyrus has a single rooted Heirarchy. One very useful feature for many of us having to manage multiple domains would be a multi-rooted tree so that the "Shared Folders" of one domain didn't "bleed over" into another domain. Currently, the only way that I can see to implement this without globally managing the ACls is to run multiple master processes with different configuration files (or a similar "jail" environment to create the separate mail stores). I would suggest looking at taking the Alternate Namespace patch to a next level, where any folder can be exported anywhere in heirarchy. So the shared folder,/company1.dom/SharedGroupingA/Shared1 can be exported as /Shared1 similar to the way the subfolders of Inbox are exported as if they were at the top level. I would also like the ability to create separate heirarchies, where upon user login they get relegated to particular subtree as their root directory to create the closed shared folder environment for virtual domain support I mentioned above. Neither of these seem like a trivial patch, but might be worth looking into. -- Michael -- On Sun, 2001-09-23 at 06:04, Norbert Sendetzky wrote: > Hi all > > In this message I want to describe a feature I think it's worth > discussing. AFAIK no other imap server currently implemented anything > like this (please correct me, if I'm wrong). > > Until now, the mailbox system of Cyrus imap is more or less flat. > There are numerous mailboxes of users and public folders one level > below the root mailbox (this one you see if you connect as > administrator), which can contain subfolders. This is why I called it > "more or less flat". Users are only known to the imap server, if > there is a mailbox below the root which belongs to them. There is no > such thing as automatically generated shared folders for all or > groups of users. > > My suggestion would be that mailboxes can be part of a mailbox/shared > folder tree. Two examples (sf* are shared folders and mb* are > Mailboxes): > > sfAll > -mbUserA > -mbUserB > -mbUserC > > sfAll is a shared folder for all mailboxes below (mbUserA, mbUserB, > mbUserC). > > > Now a more complex one: > > sfAll > -sfLocationA > --mbUserA > --mbUserB > -sfLocationB > --mbUserC > --mbUserD > --sfDev > ---mbUserE > ---mbUserF > --sfTec > ---mbUserG > > sfAll is a shared folder for all users (A-G), sfLocationA for mbUserA > and mbUserB and sfLocationB for C-G (and so on for sfDev and sfTec). > All nodes in this tree are therefore shared folders and all leafs are > mailboxes. > > The user mbUserF can for example post messages into sfDev, > sfLocationB and sfAll and can therefore reach all people below the > level of the shared folder he posted. > > I hope I clarified my suggestion and appreciate any comments. > > Regards, > > > Norbert
