dovecot - Jun 2011 - dovecot-metadata-8 released

Hello everyone!

I just released dovecot-metadata-8, which is an implementation of RFC 5464 
(IMAP METADATA), allowing to add comments/annotations/metadata to folders of 
an email account.

The major feature is that it works with Akonadi, or more specifically the 
Kolab backend thereof, while being dovecot-2.0 compatible.

The module consists of 3 plugins, two IMAP frontends and one backend:
 * "imap-annotatemore" is a partial implementation of
draft-daboo-imap-
annotatemore-08 (early predecessor to RFC 5464), based on work by Bernhard 
Herzog (Intevation GmbH). The sole intention is to support Kolab, not to 
strictly implement the draft.
 * "imap-metadata" is a complete implementation of RFC 5464. Kolab
clients do
not (yet) use these commands.
 * "metadata" is the common backend

imap-metadata and metadata were entirely written from scratch, while imap-
annotatemore is an adaption of the work by Bernhard Herzog to the new backend.

You can download the code via Hg [1] or as exported tarball [2] from the Hg 
webinterface.

Please note that the README is outdated, as are some other files.

The build process is pretty much straightforward, just make sure you have the 
dovecot headers available on your system:
./autogen.sh
./configure --with-dovecot=/path/to/dovecot
make
make install

Next you need to adjust your dovecot config. The following works for me:
== dovecot.conf =dict {
  metadata = file:/var/lib/dovecot/shared-metadata
}
== 10-mail.conf =mail_plugins = ... metadata
== 20-imap.conf =protocol imap {
  mail_plugins = $mail_plugins ... imap_metadata imap_annotatemore
}
== 90-plugin.conf =plugin {
  metadata_dict = proxy::metadata
}

To allow a Kolab client to find (e.g.) the addressbook folder, issue this IMAP 
command after login:
SETMETADATA "path/to/folder"
("/shared/vendor/kolab/folder-type" "contact")

If you find any bugs (crashes, incompatibilities with RFC 5464, etc), please 
write me a mail. Be advised that this code is still experimental and might 
crash your server!

@Timo: Please have a look at the src/*-ext.[ch] files, they contain extensions 
to the dovecot libraries and might be useful for others, too.

Kind regards,
Dennis Schridde

[1] http://hg.dovecot.org/dovecot-metadata-plugin
[2] http://hg.dovecot.org/dovecot-metadata-plugin/archive/bdf2445e101f.tar.gz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20110612/836dde0a/attachment-0002.bin>

Hi Dennis,

On 6/12/2011 3:55 PM, Dennis Schridde wrote:
> Hello everyone!
>
> I just released dovecot-metadata-8, which is an implementation of RFC 5464
> (IMAP METADATA), allowing to add comments/annotations/metadata to folders
of
> an email account.
Nice!

I've browsed the source a little and I compiled it, but I haven't 
actually tested it yet. However, I have a few comments/requests already.
> The build process is pretty much straightforward, just make sure you have
the
> dovecot headers available on your system:
> ./autogen.sh
> ./configure --with-dovecot=/path/to/dovecot
> make
> make install
I had some compile problems. First of all, my Debian stable has automake 
1.10 and thus does not support the new silent-rules feature. I'd suggest 
the following patch to maintain backwards compatibility for the time being:

diff -r 8077ad9bce6f configure.ac
--- a/configure.ac      Sun Jun 12 13:54:06 2011 +0200
+++ b/configure.ac      Mon Jun 20 10:36:29 2011 +0200
@@ -1,7 +1,9 @@
  AC_PREREQ(2.65)
  AC_INIT([dovecot-metadata],[8],[devurandom at gmx.net])

-AM_INIT_AUTOMAKE([1.10 silent-rules])
+AM_INIT_AUTOMAKE([1.10])
+m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES])
+
  AM_MAINTAINER_MODE

  AC_CONFIG_MACRO_DIR([m4])

Also, I usually like to compile against an uninstalled Dovecot source 
tree, e.g. to perform tests without installing anything. This failed 
because the currently installed dovecot.m4 does not provide 
LIBDOVECOT_IMAP_INCLUDE. Timo, could you fix this?

diff -r 327486d79620 dovecot.m4
--- a/dovecot.m4        Thu Jun 16 16:37:42 2011 +0300
+++ b/dovecot.m4        Mon Jun 20 10:33:29 2011 +0200
@@ -62,7 +62,7 @@
         AX_SUBST_L([DOVECOT_CFLAGS], [DOVECOT_LIBS], 
[DOVECOT_SSL_LIBS], [DOVECOT_SQL_LIBS])
         AX_SUBST_L([LIBDOVECOT], [LIBDOVECOT_LOGIN], [LIBDOVECOT_SQL], 
[LIBDOVECOT_LDA], [LIBDOVECOT_STORAGE])
         AX_SUBST_L([LIBDOVECOT_DEPS], [LIBDOVECOT_LOGIN_DEPS], 
[LIBDOVECOT_SQL_DEPS], [LIBDOVECOT_LDA_DEPS], [LIBDOVECOT_STORAGE_DEPS])
-       AX_SUBST_L([LIBDOVECOT_INCLUDE], [LIBDOVECOT_LDA_INCLUDE], 
[LIBDOVECOT_SERVICE_INCLUDE], [LIBDOVECOT_STORAGE_INCLUDE], 
[LIBDOVECOT_LOGIN_INCLUDE], [LIBDOVECOT_CONFIG_INCLUDE])
+       AX_SUBST_L([LIBDOVECOT_INCLUDE], [LIBDOVECOT_LDA_INCLUDE], 
[LIBDOVECOT_SERVICE_INCLUDE], [LIBDOVECOT_STORAGE_INCLUDE], 
[LIBDOVECOT_LOGIN_INCLUDE], [LIBDOVECOT_CONFIG_INCLUDE], 
[LIBDOVECOT_IMAP_INCLUDE])

         DC_PLUGIN_DEPS
  ])

The fact that this package relies on an installed dovecot.m4 also makes 
compiling against an uninstalled source tree a bit of a chicken-egg 
problem. Pigeonhole includes a  version of dovecot.m4 (albeit modified) 
in the distribution for this purpose, but I am not sure that is the best 
solution. Also, since compiling against an uninstalled Dovecot currently 
has no real purpose for this package for now (it may have when I 
implement the related Sieve features as discussed below), I would not 
give fixing this any priority at all.
> If you find any bugs (crashes, incompatibilities with RFC 5464, etc),
please
> write me a mail. Be advised that this code is still experimental and might
> crash your server!
Now that Dovecot has IMAP METADATA support, it would be nice to 
implement the Sieve side of the story as well. This is specified in 
RFC5490 (http://tools.ietf.org/html/rfc5490). These Sieve language 
extensions allow matching against server and mailbox annotations in 
Sieve scripts.

To build Sieve plugins for the aforementioned features, I would need to 
have access to the metadata backend to read the annotation entries. For 
that reason, I would like to suggest that you put the metadata storage 
backend in a separate shared library, such that other future plugins and 
tools can link against it to gain access to the metadata storage. 
Pigeonhole does something similar already; the Sieve interpreter is 
installed as /usr/lib/dovecot/libdovecot-sieve.so and the LDA plugin 
makes use of it, as do command line tools such as sieve-test.

Regards,

Stephan