[Kolab-devel] Is IMAP still the right choice?

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Wed Nov 30 13:32:22 CET 2011

On 2011-11-30 10:52, Georg C. F. Greve wrote:
> On Wednesday 30 November 2011 10.18:35 ABBAS Alain wrote:
>> 1) the speed and performance
> This is primarily an issue of using IMAP efficiently, though.
> A practical example: The Z-Push backend currently iterates over every
> annotation in every folder for both private and shared name spaces
> one command
> at a time, so 2 * n * x commands & responses.
> The same can be done in a single command & response.

Note that, on a Kolab 2.3 server (Cyrus IMAP 2.3), CONDSTORE is not 
enabled for mail folders by default. Polling for updates on the 
server-side of things becomes a lot more complex without it. I don't 
think Z-Push's Kolab backend (through Horde) currently uses this 
functionality even when enabled, but if it does, the following could 
mean a significant performance improvement as well;


>> 2) not really full search functionnality (try to search for an event 
>> for
>> example without cache who is a really a bad thing on a big calendar 
>> (you
>> must iterate all the mails .....)
> Again: You can search for the event's UID in IMAP, cached by server.

Note that the indexing job that is squatter is not enabled by default 
on a Kolab 2.3 server. This is the indexing job that makes searches that 
do not just include header searches, not have to read all files in a 
mail folder.

A line that would enable that, to add to one's 
/kolab/etc/kolab/templates/cyrus.conf.template, would be:

   squatter    cmd="squatter -s -i" at=0130

in the EVENTS section.

> That's not to say there are cases where you want caching for
> different access modes, but that is always the case no matter which 
> storage backend is chosen.
>> 3) duplicate info for some groupware object ( not easy without a lot 
>> of code
>> to have for example things like free busy or the status....)
> Virtually every server I know of pre-generates free/busy, and for 
> good
> reasons, independently of the storage used, has nothing to do with 

I think there may be one exception,  Exchange 2010 EWS ;-)

>> 4) lack on the permissions Impossible to have a granularity like a 
>> bdd or
>> LDAP (example PRivate sensitivity who is just a software bit in the 
>> format
>> we have with imap just
> The more complex ACLs, the more easy to screw it up.
> I am not sure I want users to be able to touch anything even remotely 
> as
> complex as LDAP ACLs, that would just be inviting accidental leaks
> and lots of trouble.

I can give you the most complex LDAP ACL to use in a Cyrus IMAP ACE and 
it'll all be dandy to the user. It's called dynamic groups.

On the subject of privacy/sensitivity, currently IMAP is the only 
technology worked on that can make things *actually* private. It's 
called per message annotations, of which the private side can store a 
key to decrypt the contents of a message with, so that only 
john.doe at example.org is eligible to read (parts of) the contents of a 

Up and until now, privacy either meant messages in a folder that no-one 
else had access to, or a client recognizing a 'private' flag having been 
set and thus not displaying the message contents (despite the fact the 
message is actually readable in full detail).

Kind regards,

Jeroen van Meeuwen

Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08

More information about the devel mailing list