Re: [Evolution] (cyrus) shared folders still not supported?

[Patrick O'Callaghan <poc usb ve>]

On Thu, 2008-01-31 at 14:09 -0500, Brian J. Murrell wrote:
> On Thu, 2008-01-31 at 14:21 -0430, Patrick O'Callaghan wrote:
> > On Thu, 2008-01-31 at 11:51 -0500, Brian J. Murrell wrote:
> >  
> > > Let me ask then, in your cyrus account in evolution, typically you see
> > > this hierachy:
> > >
> > > Inbox
> > >   folder 1
> > >   folder 2
> > >     sub-folder 1
> > >   folder 3 
> > >   ...
> > > Junk
> > > Trash
> > >
> > > Where in that layout do your public folders show up?
> >
> > Sorry for not replying earlier. I've asked the guy who set this up but
> > he hasn't got back to me yet.
>
> NP.
>
> > Anyway, on our server I see a structure
> > like this (from Evo):
> >
> > Inbox
> > Folder 1
> > Folder 2
>
> Ahhh!  This is interesting.  Your folders are not considered subordinate
> of INBOX.  I think that's the "altnamespace" feature switch of Cyrus
> IMAPD.  Perhaps I should give that a try.
>
> > Junk
> > Public Folder
> >   Subfolder 1
> >   Subfolder 2
> > Trash
> > Whatever
> >
> > I see the same thing from Thunderbird and from our Webmail system (based
> > on IMP).
>
> Great to know.
>
> > Note that our Cyrus is configured in "anonymous root" mode rather than
> > the default "Inbox root" you seem to have, but I can't believe that
> > makes a difference wrt shared folders.
>
> Is "anonymous root" aka "altnamespace":
>
>        altnamespace: 0
>             Use the alternate IMAP namespace, where personal folders
> reside at the same level in the hierarchy as INBOX.
>
> > I'll write again if I get further info.

OK, as promised, here's the scoop. I'm basically just quoting here, with
some edits for clarity, so if you have questions I can forward them or
just put you in touch with the guy directly.

        You have to configure Cyrus to do shared folders -- it doesn't
        do it be default. This involves deciding on a naming scheme and
        names for the (up to two) namespaces. [It's] all explained in
        the relevant documents. I'll try to drag the info out of my
        head, knowing that I'm bound to miss something.
        
        The idea is to edit /etc/imapd.conf (or wherever the Cyrus 
        install puts that file) and add or change the sharedprefix
        entry 
        to the desired name under which will appear all the shared 
        folders; it should be something that can be understood and
        won't 
        conflict with whatever naming scheme the server uses. The shared
        folders will appear to the user to be under a pseudofolder
        (pseudo because it cannot contain messages).  The location of
        that pseudofolder relative to the user's INBOX is what Cyrus'
        naming scheme controls.
        
        I prefer to set what Cyrus calls the "alternate" namespace,
        where 
        user's folders appear at the same level as the INBOX 
        (the "regular" or "classic" namespace has them *under* the 
        INBOX); in this namespace, the pseudofolder appears along all 
        other folders the user might have (hence the need for
        reasonable 
        uniqueness).  With the default namespace setup the pseudofolder 
        appears alongside the INBOX, so there's no collision possible 
        (unless the pseudofolder is foolishly named "INBOX"...).

                [Our public space is called "Cartelera" (Spanish for
                Noticeboard) but you can use what you like. The various
                public folders then hang from this. -- poc]
        
        Shared but non-public folders are also part of the pseudofolder
        scheme, but use another pseudofolder called userprefix instead
        of 
        sharedprefix. Everything else works essentially the same. On
        login any folders under Cyrus' "user." hierarchy whose ACLs
        allow reading by the user will populate this pseudofolder, and
        will retain their full hierarchy.  For example, if the
        pseudofolder was named USERS and you had a folder user.poc.xx.yy
        whose ACLs let it be read by Pete, then on login Pete would see
        in his MUA something like
        
            USERS
                   poc
                       xx
                          yy
        
        where he would have no access whatsoever to poc and xx (except
        to 
        see the required subfolder(s)), but would be able to see the 
        contents of yy.
        
        To summarize: on login Cyrus does a search for every folder
        that 
        has the appropriate ACLs and sorts them into 3 categories:
        those 
        under "user.LOGINUSER", those under other "user." folders, and 
        any other not under "user."  The first are the user's own
        folders 
        and occupy the main namespace; the second are the privately 
        shared folders, and occupy the userprefix namespace; and the 
        third are the publicly shared folders and occupy the
        sharedprefix namespace. (This search is, of course, very quick
        due to the various databases Cyrus uses.)

        Note that only shared folders with ACLs marking them readable to
        a given user (or to all users) will appear. If the ACLs are set
        wrong there could happen many (apparently) weird things, which
        become quite reasonable when you start to think about how ACLs
        work.  In particular, it is customary to give public folders an
        ACL that grants read rights to anybody.

        The way a user sees his INBOX and other folders, together with 
        the pseudofolders, is determined by the server's namespace 
        setting.  But the way Cyrus sees and understands folders --
        shared or otherwise -- is fixed.
        
        A user INBOX is always called "user.USERNAME"; folders for that 
        user are called "user.USERNAME.FOLDERNAME"; and so on, 
        recursively ad nauseam.  Public folders, on the other hand, are 
        always called "FOLDERNAME", without further qualification, and 
        in particular without the "user." or any other prefix. Anything 
        without an "user." prefix will be shown to the user under the 
        public pseudofolder (i.e. the sharedprefix), if the folder's
        ACLs allow it.
        
        So, the admin has to both set up the server
        (via /etc/imapd.conf) 
        and create some shared folders using the appropriate admin 
        tools, making sure to set the ACLs just right.
        
        Finally, there's the issue of delivering content to the shared 
        mailboxes.  That's left as an excercise for the student :-)

Hope this helps.

poc