Re: [Evolution] Posting (not sending) messages

On Fri, 2010-08-06 at 15:45 +0100, Sam Liddicott wrote:
On 06/08/10 14:37, Patrick O'Callaghan wrote:

On Fri, 2010-08-06 at 11:07 +0100, Sam Liddicott wrote:
Can I also recommend that one of the devs signs up for a free account on - they offer IMAP access to their forums.

I think you'll find that evolution 2.30.2 will load the shared folders
and namespaces fine the first time, but when you quit and re-start
evolution you will see that all the folders and namespaces disappear a
while after loading. A quick visit to Folder Subscriptions will make the
top level folders re-appear (in the left pane) even though it shows the
whole tree of folders in Folder Subscriptions. It is them impossible to
get the sub-folders.
Could there be a problem with your IMAP server? I have several shared
sub-folders and they work reliably. They're all branches of a single
shared tree on the server, because that's how Cyrus does it.  Also, I
don't touch the default namespace settings.

Quite possibly something is wrong with the IMAP, but I don't think so. 
Evolution has only recently had added the feature of multiple namespace 
support (which citadel uses). I haven't changed the default namespaces.

There was a thread on this a couple of years ago, see

This is part of a reply I got from our server admin when I asked him
about this. It dates from the same time as the above thread. Note that
the user simply has to subscribe to the shared namespace and it should
all work:

        You have to configure Cyrus to do shared folders -- it 
        doesn't OOTB.  Than involves deciding on a naming scheme and 
        names for the (up to two) namespaces.
[I asked if there was any special magic one had to know about.]
        Quite a bit.  All explained in the relevant documents. I'll try 
        to drag the info out of my head, knowing that I'm bound to miss 
        The idea is to edit /etc/imapd.conf (or wherever the Cyrus 
        install puts that file) and add or change the sharedprefix
        to the desired name under which will appear all the shared 
        folders; it should be something that can be understood and
        conflict with whatever naming scheme his server uses.  The 
        shared folders will appear to the user to be under a 
        pseudofolder (pseudo because it cannot contain messages).  The 
        locdation 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,
        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
        uniqueness).  With the regular namespace setup the pseudofolder 
        appears alongside the INBOX, so there's no collision possible 
        (unless the pseudofolder is foolishly named "INBOX"...).
        Another detail is that only shared folders whith ACLs marking 
        them readable to a given user (or to all users) will appear 
        under the pseudofolder visible to that user.  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 shared 
        folders an ACL that grants read rights to anybody.
        Then, there's the issue of User namespaces vs. Cyrus
        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.  Shared 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 
        shared pseudofolder, if the folder's ACLs allow that.
        So, the admin has to both setup 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 that helps.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]