Dovecot public namespace and subscription behaviour

Question

Level 1

15 points

Dovecot public namespace and subscription behaviour

Hello, hope somebody can help.

I am having problems allowing some of my users to subscribe to a partiuclar public mailbox, hosted using the built-in Dovecot-based Mail service on 10.6.8 Server.

They can check the box to subscribe to a public box, but the setting does not 'stick'. The activity window reads "subscribing to mailbox xyz" for each subfolder. But when you go back to the subscriptions panel, the checkboxes are all unchecked again.

I set up a public namespace in Dovecot on 10.6.8 Server like this:

# /etc/dovecot/dovecot.conf

namespace private {

separator = /

prefix =

inbox = yes

}

namespace public {

separator = /

prefix = Team/

location = maildir:/Volumes/Drobo/Services/MailStore/Team

subscriptions = no

}

namespace public {

separator = /

prefix = Admin/

location = maildir:/Volumes/Drobo/Services/MailStore/Admin

subscriptions = no

}

###

"Team" folder has ownership throughout as follows: harry : team rwxrwx---

"HR" folder has ownership throughout as follows: sally : hr rwxrwx---

The goal is that a Team user can access just the Team public mailbox, and an HR user (who is also a member of Team) can access both HR and Team public mailboxes.

-------------

I want to control the permissions to these mailboxes using POSIX permissions, as set above. The good news is that in Mail.app on a 10.6.8 client, these permissions seem to be taking effect correctly in the "Subscriptions" panel. A "Team" user cannot drill down into the HR mailbox.

The Problem

My HR users are able to see both the mailboxes correctly.

However, my Team users are unable to subscribe to their public mailbox. They can click to subscribe, all the subfolders get ticked, but as soon as you navigate away from Subscriptions panel the settings get lost.

This leads to my questions:

- How are subscriptions managed in this case? Is it server-side or client-side?

- What is the impact of choosing "subscriptions = no" in my configuration file? What if I set this to yes?

- Will any of these settings cause my clients to "auto-subscribe" to newly created mailboxes by other users?

Any help is greatly appreciated.

Thanks!

Posted on Mar 27, 2012 1:39 AM

Reply

Answer 1

Apr 11, 2012 8:41 AM in response to jimbo2k

Having similar issues with Lion Server, dovecot, Mail.app 5.2.

Clients using Lion 10.7.3.

Doing similar things - sharing public folders among team mates, who each have their own private accounts.

And though it took a while, I seem to have got it working. Mostly.

Users can now see public folders in the public namespace. They can see, in the Subscription window, all available Public folders, and can check the Subscription boxes to sign up. This seems to last while the Server is on (Mail.app opens and closes, subscriptions are maintained), but when Server goes down and comes back, subscriptions are forgotten. They can be re-subscribed without issue, but nobody wants to start each day by going to find their Public folders again.

in /etc/dovecot/dovecot.conf, I have:

namespace {

type = private

separator = /

prefix =

inbox = yes

}

namespace {

type = public

separator = /

prefix = Project Folders/

location = maildir:/var/spool/imap/dovecot/public

subscriptions = no

}

it took type = public to get the namespace to show up properly. and I moved the public namespace up (out of /var/spool/imap/dovecot/mail ) on same external advice.

but now subscriptions come Un-Stuck.

trying, now, subscriptions = yes in the public.

any other ideas?

Besides, that is, use Thunderbird or Eudora OSE. I can do that, but strongly prefer Mail.app if I can get it functional and reliable. Thunderbird /Eudora OSE is working fine, but the interface cluttered. okay: ugly.

Reply

Answer 2

Apr 11, 2012 8:04 PM in response to andrewcoldhamandhartman

subscriptions = yes

seems to set the last person's subscription preferences to all subscribers. no good. rats.

Reply

Answer 3

Apr 12, 2012 1:28 PM in response to andrewcoldhamandhartman

with subscriptions = no, I need a place to store my users' INDEX files. they are network users, without home directories on this server, so I made it somewhere close by:

namespace {

type = public

separator = /

prefix = Public/

location = maildir:/var/spool/imap/dovecot/public:INDEX=/var/spool/imap/dovecot/index/%u

subscriptions = no

}

Other users' subscription lists were quickly refreshed (with some botching of the Read/Unread status by Mail.app), so I'm hopeful that these changes will be the last, and that we've finally got Mail doing what we want.

maybe this last piece relates most directly to you, jimbo2k?

I have in my /var/spool/imap/dovecot/public folder, a file called subscriptions, which was constantly being touched by the latest user. And I thought everyone was reading from it. With an explicit location for INDEX now, are users now keeping their individual preferences for subscriptions better? I'll know tomorrow.

Reply