On Tue, 2005-03-15 at 13:18 +0000, Chris Wakelin wrote:

Of course, I meant "namespace private" (I'd just tried "public" in case it made any difference, but I think Dovecot doesn't really support shared folders yet).

It's shown to clients that ask for NAMESPACE, so there is some difference. Dovecot probably will never internally care what about their difference.

Something like the following seems to work using the (undocumented?) CONTROL= option.

Ah, you found it. :)

namespace private { separator = / prefix = "#snapshot/" location = maildir:%h/Maildir/.snapshot/nightly.0:
INDEX=/var/indexes/%u:CONTROL=/var/indexes/%u hidden = yes }

dovecot-uidlist and temporary files seem to be created in the "CONTROL" directory.

Is it a good idea to use "CONTROL=" for NFS-mounted maildirs anyway (read-write ones as well) to store these files on the local filesystem?

Well.. Since those are rarely accessed anyway, I don't think it matters where they're located or if they're deleted/lost once in a while.

Normally the control files shouldn't be lost, dovecot-uidlist especially.

Dovecot doesn't care if you use mixed NFS/local filesystems.

I've had a go at adding a "readonly" namespace option to dovecot-1.0-stable. My idea is to provide access to NetApp ".snapshot" versions of NFS-mounted maildirs to let users recover their own messages. I'm not sure whether anyone else would find it useful, but here it is in case :-)

There are two patches, one to add the option, the other to add some checking to various IMAP commands just in case the client doesn't behave itself when told the mailbox is read-only ;-)

It's used something like :

namespace private { separator = "/" prefix = "#snapshot/" location = maildir:%h/Maildir/.snapshot/nightly.0:INDEX=/export/mail/%h/.S napshot-indexes:CONTROL=/export/mail/%h/.Snapshot-indexes hidden = yes readonly = yes }

I've not tested it very thoroughly, and none of our users have Maildirs on the NetApp yet ...

Of course, this will all be redundant when we have ACL support.

Best Wishes, Chris

On Tue, 15 Mar 2005 23:06:24 +0200 Timo Sirainen <tss@iki.fi> wrote:

On Tue, 2005-03-15 at 09:11 +0000, Chris Wakelin wrote:

...

Is it possible to have folders on read-only partitions in Dovecot 1.0-stable?

Only if you set the permissions so that Dovecot really doesn't have write access there. Other permission checks will come with ACL code some day..

--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094

Timo Sirainen wrote:

On 19.5.2005, at 18:15, Chris Wakelin wrote:

...

I've had a go at adding a "readonly" namespace option to dovecot-1.0-stable. My idea is to provide access to NetApp ".snapshot" versions of NFS-mounted maildirs to let users recover their own messages. I'm not sure whether anyone else would find it useful, but here it is in case :-)

There are two patches, one to add the option, the other to add some checking to various IMAP commands just in case the client doesn't behave itself when told the mailbox is read-only ;-)

How about if the readonly setting was set as parameter in location setting, so the storage code could handle it itself and set itself to read-only state? Dovecot already supports read-only mboxes and maildirs so I think this way you wouldn't have to add extra readonly-checks.

That might be better, but two lots of code to write, I guess! I think there might still need to be checks for the commands, I tried opening a folder with "EXAMINE" rather than "SELECT" and seeing if Dovecot would let me alter flags and it did ...

Although you'd still have to add checks for create/delete/rename commands and that code would be mbox/maildir specific then..

Yes, that's where it gets messy. In my version, I don't like having to have a special function to check the namespace flag, and the checks only work for the case where it's the namespace option that's made the folder readonly, so it's not very general.

But as you said, ACLs would be the real solution :) Hmm. Perhaps it's time to start thinking about those too. Normally ACLs would be set by user itself for his own mailboxes. That case should be pretty simple. We could use some ACL-file and possibly filesystem's own permissions as well. I think for public folders you'd also have them in some namespace, and the ACLs be defined in there in a separate ACL-file.

I think ACLs would be nice, but not as important to me as say, allowing specific folders to be in different filesystems or formats (maybe a little like Cyrus' mailboxes database - ideally I want INBOXes and "Sent Items" folders on our mirrored NetApps for redundancy and the rest on our local RAID5 arrays ...)

With ACLs, how about being able to define a default ACL for each namespace (generalising my "readonly" option) and optionally allow users to override it for their folders? Perhaps the user-specified ACL can be stored in a special header in the folder like X-IMAPbase (or is that asking for trouble?) to save having to open another file for each folder.

But what about the kind of ACL-support your snapshots-case would need? It's kind of a special case because it's a namespace that points to different location for every user. I think this falls into same category as nondeletable folders that some people want for Drafts/Trash/etc. Would we need some globally defined ACL blocks in configuration file where you can give a list of folder masks where it's effective? Maybe..

That might also be a way of generalising the folder location, but I thought that might be quite hard to implement (beyond me anyway!).

Maybe something like :-

namespace private { separator = / prefix = acl = owner:rwcd

folder Trash { acl = owner:rw location = /export/cheap/storage/%u/[] } folder Sent* { location = maildir:/export/mirrored/%u/[] } }

namespace private { prefix = "#snapshot" location = maildir:/export/mirrored/.snapshot/nightly.0/%u acl = owner:r }

namespace public { prefix = "#public" acl = owner:rwcd everyone:r location = maildir:/export/public }

where r/w/c/d is read/write/change acl/delete?

I'm not sure how that would fit in with file permissions though!

Best Wishes, Chris

-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094