KONSEC work on Cyrus IMAPd

[Martin Konold]

Am Dienstag, 15. August 2006 17:15 schrieben Sie:

Hi Ken,

> > 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.

Yes but it implements the older and expired 
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-03.txt 
which used to announce its capabilities with the string LISTEXT.

The current draft changed to the new capability LIST-EXTENDED. I am to keep 
LISTEXT while developing LIST-EXTENDED.
  
> > The LIST-EXTENDED capability is the prerequisite for the most recent
> > METADATA extension as described in

> > 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.

Hmm,... I fail to understand this. How is folder METADATA different from 
foldernames or messages. For neither folder names nor messages we limit the 
allowed contents/names beyond what is required by the standard or unfortunate 
side effects of the implementation.

I am considering a simple solution which means that the mailbox acl (per 
folder) controls the access to the contents and the metadata of the folder. I 
don't want to restrict the contents of either a folder or the meta data. The 
resources used for both shall be accounted for when doing the quota 
calculations.

How can you imagine abuse which needs to be prevented?

> 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.

Yes, I am only talking about annotations used (read/write) by the clients.

> 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.

With Kolab calendar folders are opaque to the imap server. The Cyrus IMAPd 
does not need to know anything about the contents. Actually I consider this a 
significant strength of the solution as this built on the original imap 
principle of being agnostic with regards to the contents/data. Actually I am 
objecting of turning an imap server into an application server. IMHO imap is 
nearly perfect message storage server. Cyrus IMAPd is very well suited to 
store/retrieve data in an extremly efficient and scalable manner (according 
to my measurements and theoretical considerations much faster and more 
scalable than e.g. web servers)

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

Yes, I also want to hear opionions. Firstly about the new LIST-EXTENDED 
capability and secondly about implementing the METADATA draft.

Yours,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker