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