Horde Upgrade

jimc, 2006-04-28

We've had Horde installed for about a year doing only webmail (IMP). Now we want to put a database backend on it, and activate the other features.

Horde Framework has a critical security fix applying to v3.0 and above. 3.0.10 or 3.1.1 are the fixed versions. Our version: 3.0.5 installed 2005-08-25. Look in papyrus:/h1/www/htdocs.

Horde features:


Web mail. The database holds user preferences. There is no mention of pre-indexed mail in the database.

We have this in production.

Versions: Latest 4.1; ours 4.0.3


Contact manager (address book). You can import and export address books in these formats: Pine, Mulberry, CSV, TSV, vCard. You can share address books with other users. Obviously the address book is stored in the database.

We want this.

Versions: Latest 2.1


Mail filter rules manager. It's a gui that can create (and apply, for IMAP) filter rules for Sieve, Procmail, Maildrop and IMAP. Docs refer to special rulesets for blacklist, whitelist, forwarding, and vacation. Looks like the rules are saved in the database.

I don't know how useful this is, but we probably want it. I believe Ingo is not a general anti-spam program; I think it's actually a classifier.

Versions: Latest 1.1


Calendar application, with integrated collaboration and scheduling features. Shared calendars. iCalendar format (import and export? not sure). Requires authentication. SQL and Kolab backends, i.e. this is where it saves the calendar data. It can do e-mail notifications.

We want this.

Versions: Latest 2.1.1


Task list application. It is very similar in functionality to the Palm ToDo application. It has iCal and Sunbird (import-export format?) support. It can do e-mail notifications. Presumably the task list is stored in the database.

We want this.

Versions: Latest 2.1


Notes and Memo application, similar to the Palm Memo application. This is for generic notes that don't fit as a contact, a todo or a calendar event. Presumably the notes are stored in the database.

We probably want this.

Versions: Latest 2.1


CVS repository viewer. No database implications beyond user preferences.

We don't care about this but Yalin Wang might.

Versions: Latest 2.0.1


File Manager. The files can be on the real local filesystem, FTP server, or in a SQL database. The CVS version (to be released as v1.1) can let you edit the content either as flat text or as HTML.

Can of worms; we probably want to avoid this.

Versions: Latest 1.0.2


Change your password over the web.

Probably we want to avoid this.

Versions: Latest 3.0


Edit your .forward file using FTP to snarf/deposit it.

Sounds pretty useless, at least for us. But on systems without shell accounts it could be very helpful. Versions: Latest 3.0


Mail reader optimized for use on a PDA. Includes basic functionality from IMP including viewing, deleting, replying, forwarding, composing.

Not useful for Mathnet, but worth investigating for Maemo.

Versions: Beta 1.0-RC1

Vacation (BETA)

Edit your .vacation message using FTP to snarf/deposit it.

Cute, maybe we want to try it, maybe not. Versions: Beta 3.0-RC1

A major part of the project will be to find out how to synchronize a PDA with the web contacts - calendar - etc.

Supplementary: Kolab is a KDE groupware server and client. The server supposedly supports both KDE and Microsoft Outlook clients. Server and client are Free Software.

It looks like all the PIM functions make heavy use of a backend database. The philosophy in Horde is to have the database functions abstracted into a backend interface. Kronolith apecifically mentions being able to use Kolab. Since Kolab can talk to Microsoft Outlook as well as KDE-Kontact, we should seriously investigate whether the other Horde apps can use Kolab, and if so, whether we want to use Kolab.

Kolab does not use a backend database. Instead, it uses imap to get at groupware folders (files) in the user's Mail subdirectory. The data is stored as XML with Kolab's special ontology (which may or may not have similarities to competing products). An advantage of this approach is that when a user's account expires, his Kolab files disappear automatically.

Kolab uses LDAP for authentication. Therefore a prerequisite is a working LDAP server. We want to move in this direction anyway, to retire NIS in favor of something more able to resist network storms.