KONSEC work on Cyrus IMAPd

[Ken Murchison]

Martin Konold wrote:
> Hi,
> 
> KONSEC (www.konsec.com) is working on implementing support for METADATA in 
> Cyrus IMAPd.
> 
> Most of the work is done by Levin Fritz <levin.fritz at konsec.com> and I am 
> supervising the work.
> 
> A first step is the development of the LIST-EXTENDED capability.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-17.txt

As I said before, the beginnings of this extension is already in the code.

> The LIST-EXTENDED capability is the prerequisite for the most recent METADATA 
> extension as described in 
> 
>      http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-09.txt
> 
> Ken: You mentioned that you want to limit what the client is allowed to store 
> in the annotations using something like a white list and ACLs.
> 
> What is the basic idea behind this?
> 
> Why do you want to limit the client to only allow it to store a limited number 
> and types of annotations? 
> 
> After all the plain folder ACLs already govern the access and provided that 
> the space used is accounted for in the quota calculation I am wondering about 
> the rational?
> 
> Do you want to go beyond/extend draft-daboo-imap-annotatemore-09.txt?
> 
> What about the implications of run-time parsing an external file?


As an underlying principal, I think it is reasonable for an admin to 
have control over what a client can store on the server.

I suppose that if the annotations stored by the client are only used by 
the client (config options, etc), then I don't have any objection to 
using just the mailboxes ACL.

If however, we're talking about tagging a mailbox so that the server 
treats the mailbox differently (calendar data, etc), then I think we 
want to tighten up the access.

I'd like to hear other opinions on this topic.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University