[Dovecot] Read-only mail folders / ACLs

Chris Wakelin c.d.wakelin at reading.ac.uk
Tue May 24 01:44:12 EEST 2005

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,

Christopher Wakelin,                           c.d.wakelin at 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

More information about the dovecot mailing list