Cyrus IMAP Murder frontends are given a command similar to the following:
. GETMETADATA (DEPTH infinity) "*" "/shared/*"
They will still (hard-coded) use GETANNOTATION against backends, yielding untagged responses such as:
* ANNOTATION "Calendar" "/vendor/kolab/folder-type" ("value.shared" "event" "shared.size" "5" "value.priv" "event.default" "priv.size" "13")
A configuration item in /etc/imapd.conf of suppress_capabilities: METADATA will prevent client applications from using GETMETADATA and SETMETADATA, and therefore issue GETANNOTATION and SETANNOTATION commands, with untagged responses ANNOTATION.
However, when a client application does issue GETMETADATA, the response in a discrete Murder topology will yield untagged ANNOTATION responses -- that the client application may not parse.
The client application in question here is Guam, which has never been developed against the (now legacy) ANNOTATEMORE RFC draft -- it uses METADATA, even if the capability is suppressed.
In contrast, suppressing the METADATA make Roundcube and KDE PIM use ANNOTATEMORE and ANNOTATEMORE2 (if available).
This results in the following options:
- Make Guam use ANNOTATEMORE rather than METADATA, so a discrete Murder topology's frontends can use their (hard-coded) GETANNOTATION and SETANNOTATION,
- Change everything over to METADATA and drop ANNOTATEMORE altogether. This would include;
- Changing Cyrus IMAP to use METADATA internally, and
- Working around the lack of METADATA support in Python's imaplib (through cyruslib, shipped as part of PyKolab), updating calls to getannotation() and setannotation() functions used internally by PyKolab, and
- Optionally, dropping support for ANNOTATEMORE and ANNOTATEMORE2 from clients including Roundcube, Roundcube Kolab Plugins and KDE PIM and Kube.