[Dovecot] workaround for shared maildirs
Hello, this is my first post to the list.
I have several mailservers running courier-imap, but am planning to
convert one (and maybe more) to dovecot 1.1.4. In the process I am
also looking to finally implement shared maildirs.
As it is well known some clients (notable Apple's Mail) have problems
in showing shared folders if the correct private namespace (INBOX) is
set in the client, as only folders beneath the INBOX root are displayed.
I have seen some solutions proposed, but none satisfactory.
As the problem stems in the invisibility of secondary namespaces from
Mail.app, I though that tricking the namespace prefix to push the
shared mailboxes inside the private INBOX namespace could be a
solution and tried the following:
namespace public { separator = . prefix = INBOX.Public. inbox = no location = maildir:/SharedMaildirs/Public:CONTROL=~/Maildir/ control/Public:INDEX=~/Maildir/index/Public hidden = yes list = yes subscriptions = yes }
note the bogus INBOX.Public prefix.
Note also that CONTROL might be better not set as this is a Maildir
(see Keyword sharing in http://wiki.dovecot.org/SharedMailboxes)
Initially I had defined an additional public namespace with the same
maildir and a normal prefix, but this seems not necessary.
Well, after some tests from Thunderbird, Mail and cone (yes, the
courier UA) I can say it works . Still have to check Outlook and
Opera, but this is encouraging.
As the public namespace Public is actually contained inside the
private (INBOX), as if it was a private mailbox (with no messages)
called Public, it is actually possible to create such a mailbox inside
INBOX and end up with a private mailbox called Public containing
private messages AND public mailboxes... Any mailbox that a user
creats inside Public instead, will end up being a public mailbox as
expected.
Thanks or any comments.
Giuliano
On S 18 Oct, 2008, at 22:06 , Giuliano Gavazzi wrote: [...]
namespace public { separator = . prefix = INBOX.Public. inbox = no location = maildir:/SharedMaildirs/Public:CONTROL=~/Maildir/ control/Public:INDEX=~/Maildir/index/Public hidden = yes list = yes subscriptions = yes }
Tested also with dovecot-1.2.alpha2. As for file permission, my dovecot-shared is
-rw-------+ 1 dovecot staff 0 Oct 18 14:58 dovecot-shared
(all users belong to group staff).
Since this does not give access to the group, I have also an inherited
ACL (file system ACL) that gives read/write access those users (or
group of users) who need access to the public folders.
Works well, as far as I can tell, with no more:
... fchown() failed with file ...
on the index file. It turned out that this was happening when the
shared folders had group access.
Now, I have to work out how to limit delete to message owners (and the
T flag private) so that only owners or the administrator can delete
files.
Giuliano
On Sun, 2008-10-19 at 10:10 +0200, Giuliano Gavazzi wrote:
On S 18 Oct, 2008, at 22:06 , Giuliano Gavazzi wrote: [...]
namespace public { separator = . prefix = INBOX.Public. inbox = no location = maildir:/SharedMaildirs/Public:CONTROL=~/Maildir/ control/Public:INDEX=~/Maildir/index/Public hidden = yes list = yes subscriptions = yes }
Tested also with dovecot-1.2.alpha2. As for file permission, my dovecot-shared is
-rw-------+ 1 dovecot staff 0 Oct 18 14:58 dovecot-shared
If "dovecot" is also running login processes, it's preferrable that it's not used for anything else. Doesn't really matter here, but the login processes shouldn't have access to any files anywhere outside their chroot.
(Wonder if I could rename the dovecot user to something else.. I've previously also thought about this. dovenone, dovelogin or dovenot maybe.)
Now, I have to work out how to limit delete to message owners (and the
T flag private) so that only owners or the administrator can delete
files.
Dovecot doesn't track message owners, so this probably isn't too easy. If you use system users then I guess the owner is the file's owner. Then I can see two possibilities:
a) Modify Dovecot sources to check the owner before allowing delete flag (or expunge?)
b) chmod +t cur/ directory. But that also disallows all shared flag changes by non-owner.
participants (2)
-
Giuliano Gavazzi
-
Timo Sirainen