Kolab - A OSS Groupware Solution

All components like email, scheduling, tasks, and address book should be contained in one user interface. This is more than integrating everything in one top-level window, it also includes unifying menus, dialogs, work flows, etc.

Of course, a large part of collaborating consists in communicating, and despite all instant messaging, an powerful email client is clearly a requirement. Given that a large software package like Groupware will often be used in a corporate setting and by nomadic users, IMAP support is mandatory; for Kolab, disconnected IMAP (IMAP that does not require a permanent server connection) was added as an additional requirement.

Sphinx is a standard for email encryption and signatures developed by the German Federal IT Security Agency (BSI) for the German government. It is a mandatory requirement that clients in a Kolab system can send and receive encrypted and signed email messages according to this standard. An OSS implementation of this standard was jointly developed by Klarälvdalens Datakonsult AB, Intevation GmbH and g10code GmbH in the Ägypten project, using GNU Privacy Guard as its cryptography engine.

Kolab clients must be able to support multiple accounts per user, each of which possibly containing email messages, calendaring data, contacts, tasks, etc. Account owners can assign different access rights to other users, and accounts may even be „functional“, i.e., they belong to a group of people working together (e.g., the members of a project). Assignment of access rights must be possible both at account level and at folder level.

A Kolab user can have multiple email addresses which are all handled by the same Kolab installation. One email address is the designated primary address, the one which is always used as the sender address.

Configuration data, user databases, etc. are replicated to external servers. Accounts can be distributed over several servers for the purpose of load distribution or for the case where users are located in offices that are only connected via slow lines.

Kolab clients can define groups (sometimes also called distribution lists). A group can both be the recipient of e.g. an email message or a task, and the holder of certain access rights.

Given the distributed nature of most Kolab installations, a central networked data storage for things like public address books, user settings, etc. is necessary. It is a requirement for a Kolab system to store its information in a LDAP server according to a published LDIF scheme.

Shared folders can be created and accessed by every Kolab user with sufficient access rights. No separate logon is necessary for accessing such a shared folder.

Users can define appointments for themselves; these are entered into their calendar.

Users can schedule Meetings by creating an appointment and inviting people to it (also see below, Free/Busy Lists). Invitation messages are sent to all invitees, which in turn send answer messages containing an acceptance, a conditional acceptance or a rejection of the invitation. The user scheduling the meeting can keep track of all received answers. Some users (like managers) may be given the power to send invitations to meetings that are automatically accepted, and thus entered into the invitees' calendars.

When planning a meeting, it is important to know the availability of the intended participants at a certain date. For this, so-called free/busy lists are created that contain the times at which a certain Kolab user is already scheduled to be in a meeting. Normally, free/busy lists only contain the binary information of whether a user is busy or not, but extended free/busy lists even allow to see what a user is busy with. Users shall have the possibility, however, to mark certain appointments as personal; the contents of these will never be shown.

An additional requirement is that the generation of free/busy lists must even work when the user in question does not have a client started, e.g. when he or she is on vacation. This means that the generation of free/busy lists must be done on the server.

It is possible to define resources (e.g. conference rooms, shared company cars, or beamers). In order to reserve one of these resources, they invited to a meeting just like other users. However, in the case of resources, the Kolab server itself handles the acceptance (in case the resource is available) or rejection (in case the resource is already booked for the requested date and time).

Tasks can be created and assigned to other Kolab users. The creator of the task can follow the completion state, which is updated by the assignee as work progresses.

Kolab knows global and local address books. Global address books can be used by all users in the installation, are kept on the Kolab LDAP server, and are maintained via a special interface. Local address books are stored in the user's mail account on the IMAP server (as well as replicated on the local hard disk) and are maintained by the user via the ordinary address book interface. When searching for an address for address completion, both the global and the local address book shall be used, the search order is configurable.

The user shall be able to configure out-of-office messages that are even generated when the user has no client open (e.g., when on vacation). This means that those messages need to be generated on the server.

The server is capable of integrating virus and spam filters like amavis and spamassassin. This is configurable by the administrator by means of a web interface.

Users can be assigned quotas, a maximum amount of storage their mailboxes may occupy on the server. Quota assignment is done by the administrator via a web interface. When a so-called threshold value („soft quota“, often 80% of the real quota) is reached, the server starts to send daily email messages to the user, asking him or her to clean up his or her mailbox. If the user does not react and the hard quota is reached, neither sending nor receiving email messages will be possible until the user has deleted some mail.

Kolab servers can be run in clusters of two or more computers.

Kolab was especially conceived to allow coexistence with Outlook(tm) clients. The idea is that by using the Kolab server, users can choose whether to run MS-Windows(tm) with Outlook or Linux with the Kolab client. This requirement poses some particular challenges of its own, as we will see. Of course, as Linux enthusiasts, the Kolab developers see this not so much as a collaboration scenario, but as a migration path („first, we'll get them on our server, then we'll get them on our client“). This even includes providing a migration tool that lets users feed their .pst files (the way Outlook stores data on the local hard disk) into the Kolab server.

Since the first major installation of the Kolab system was in the German federal government, German localization of all on-screen texts and user documentation was mandatory.

The Kolab server and client should have easy installation packages, preferably one single package for the server and one for the client with as few dependencies on other installed software as possible. Installation should be as easy as running one command from the command line.

The server is based on Postfix, Apache, OpenLDAP, Cyrus IMAPD and an additional Kolab engine. The Kolab engine controls the configuration of the other parts and also takes care of handling things that need to work even when the user in question has no client running (like out-of-office replies or mandatory acceptance of meeting invitations). All configuration data is stored in the LDAP server. Of course, all email clients that support IMAP (including text-based ones like mutt) can use the email part of the Kolab server.

The KDE Kolab client is called Kontact, and is built upon KOrganizer, KMail, KAddressBook, and other components, such as KPilot for synchronization with Palms PDAs. The Kolab project has added the support for the Kolab way of scheduling, i.e., implemented an easy communication between KMail, KOrganizer, and KAddressBook, the possibility to store appointments, contacts, etc., in KMail; implemented the scheduling algorithms, implemented the handling of resourecs; implemented legacy support for broken Outlook parts; and much more. Using the Ägypten software (see above), Kontact can send invitations with S/MIME encryption and/or signatures (and of course with OpenPGP encryption and/or signatures as well).

Another group of developers is working on extending the Turba and Horde web clients to work with Kolab, resulting in a complete web client solution, something that has been asked for a long time.

It has been decided in the kdepim community to release kdepim 3.3 independently of the rest of KDE. This gives the kdepim people more flexibility regarding release dates, and the kdepim project has decided to stay compatible with KDE 3.2 for easier upgrading. The Kolab 2.0 KDE client is developed in kdepim HEAD currently, so kdepim 3.3 will contain the full Kolab client.

Lots of enhancements have been put into kdepim 3.3 in addition to the new Kolab development, such as: