KONSEC work on Cyrus IMAPd

Martin Konold martin.konold at erfrakon.de
Tue Aug 15 15:27:08 EDT 2006

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

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.

-- martin

Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker

More information about the Cyrus-devel mailing list