ACLs and such

[Hans Wilmer]

Hi,

can I set quotas and ACLs for a user named 'test' like the
following ...


cm user.test
cm user.test.archives otherpartition

sq user.test 100
sq user.test.archives 1000

sam user.test.archives test lrswipca


... and nevertheless allow user 'test' to delete mails and folders
residing under user.test.archives by default?

The point is that the user must not be able to delete his 'archives'
folder, but he must be able to freely operate on anything that resides
within that folder.

The purpose of this is to force users to automatically and
transparently move old mail to another partition that physically
resides on cheap IDE disks, but to have all mail that's accessed more
frequently stored on fast SCSI disks. This would allow to run the
server without relevant storage limitations while keeping up excellent
performance at relatively low costs.

Another approach would be an option to specify by regular expressions
that folders with certain names (like 'archive.*') are always created
on certain partitions. A more sophisticated implementation of that
would additionally allow to specify certain levels of how deeply
folders are nested in the hierarchy to decide on what partition the
folder is physically stored. Just like that in /etc/imapd.conf:


defaultpartition: default
partition-default: /var/spool/cyrus/mail

partition-newpart: /data-1/newpart
foldername-newpart: *archive.*

partition-nesting: /data-2/nesting
nestlevel-nesting: 5


Thereby, user.test would reside on /var/spool/cyrus/mail,
user.test.archive would go to /data-1/newpart, and anything nested
deeper than five folders is put to /data-2/nesting.

Maybe even a combination of nameing and nesting would be nice, though
I currently can't see its practical use.

Hm, this could be especially interesting in environments that handle
larger numbers of users:


partition-usera: /data/usera
foldername-usera: user.a*

partition-userb: /data/userb
foldername-userb: user.b*
# ... and so on


Further extend this to use some other storage method than direct
file-system access, like networked access to another server ... At
least, allow to store mails redundantly on a number of partitions for
backup purposes or for keeping a cluster of servers in sync :)


GH