imap annotations was: KONSEC work on Cyrus IMAPd
Ken Murchison
murch at andrew.cmu.edu
Fri Sep 8 09:36:52 EDT 2006
Martin Konold wrote:
> Am Donnerstag, 17. August 2006 18:53 schrieb Gerd v. Egidy:
>
> Hi Gerd,
>
>
>>didn't expect to read from you, thought you were on vacation ;)
>
>
> Well,... in the meantime (actually yesterday) I returned from vacations.
>
>
>>>How can you imagine abuse which needs to be prevented?
>>
>>I think Ken worries about annotations that are used to control server
>>behavior. Currently e.g. squatter and cyr_expire can be controlled through
>>annotations.
>>
>>In some environments it may make sense to limit access to these kind of
>>knobs, at least for some users.
>
>
> Thanks for enlighting me!.
>
> I think we need three kinds of annotations. Each kind has different purposes
> and different quota accounting rules and different ACL sets are required.
>
> 1. server annotations
> - only system administration can control server annotation
> - not necessarily set via imap but e.g. configuration files
> - typically only root can write and everyone can read the server annotations
> - no quoata or content limitations/restrictions are required as contents is ro
> for imap users anyway
>
> 2. system annotations for folders
> - stuff like controlling annotions for server side feature like the above
> mentioned quatter and cyr_expire services.
> - space required shall not be accounted for when calculating the quoata for an
> users mailbox/account
> - possible contents is strictly defined at compile time
> - Access control is not determined by the folders ACLs
>
> 3. user annotations for folders
> - generic meta data useful for some applications. This includes stuff required
> for special purpose servers like Kolab (e.g. folder-type, freebusy relevance
> etc.) and more generic information like folder creation timedate.
> - namespace is predefined and allows for arbitrary local extensions within a
> subtree
> - space used shall be considered for calculating the quota
> - possible contents is arbitrary and subject to the same ACLs like the folder
> itself
After a quick read of the above, I think you're correct. Do you have a
proposed framework for implementing and enforcing the above?
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
More information about the Cyrus-devel
mailing list