KONSEC work on Cyrus IMAPd

Martin Konold martin.konold at erfrakon.de
Tue Aug 15 00:53:05 EDT 2006


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.


"The LIST command is extended by amending the syntax to allow options
   and multiple patterns to be specified.  The list of options replaces
   the several commands that are currently used to mix and match the
   information requested.  The new syntax is backward- compatible, with
   no ambiguity: the new syntax is being used if one of the following
   conditions is true:

   1.  if the first word after the command name begins with a
       parenthesis ("LIST selection options");

   2.  if the second word after the command name begins with a
       parenthesis ("multiple mailbox patterns");

   3.  if the LIST command has more than 2 parameters ("LIST return

   Otherwise the original syntax is used."


".. defines an IMAP4 extension that is identified by the
   capability string "LIST-EXTENDED".  The LIST-EXTENDED extension makes
   the following changes to the IMAP4 protocol, which are described in
   more detail in Section 3 and Section 4:

   a.  defines new syntax for LIST command options.

   b.  extends LIST to allow for multiple mailbox patterns.

   c.  adds LIST command selection options: SUBSCRIBED, REMOTE and

   d.  adds LIST command return options: SUBSCRIBED and CHILDREN.

   e.  adds new mailbox attributes: "\NonExistent", "\Subscribed",
       "\Remote", "\HasChildren" and "\HasNoChildren".

   f.  adds CHILDINFO extended data item."

The LIST-EXTENDED capability is the prerequisite for the most recent METADATA 
extension as described in 


"The METADATA extension to the Internet Message Access Protocol
permits clients and servers to maintain "annotations" or "meta data"
on IMAP servers.  It is possible to have annotations on a per-mailbox
basis or on the server as a whole.  For example, this would allow
comments about the purpose of a particular mailbox to be "attached"
to that mailbox, or a "message of the day" containing server status
information to be made available to anyone logging in to the server."

We plan to interpret the "per mailbox" as per folder like everywhere else in 
Cyrus IMAPd.

Proper support for METADATA is required for a clean implementation of 
annotations as required by Kolab and other IMAP based solutions. See also:


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?

-- martin

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

More information about the Cyrus-devel mailing list