Interview: KDE als Kommunikationszentrale
Golem.de: Mit KDE 3.3 wird vor allem die Groupware-Suite KDE PIM zahlreiche Neuerungen erfahren. Obwohl die einzelnen Applikationen wie KMail oder KOrganizer schon lange Bestandteil von KDE sind, existiert aber erst seit KDE 3.2 mit Kontact eine gemeinsame Oberfläche. Wo sehen Sie KDE PIM heute im Vergleich zu Konkurrenten wie Evolution, Outlook oder Notes?
Im Gegensatz zu Outlook und Evolution bietet Kontact schon heute mit Kontact 1.0 eine breite Auswahl bei der Auswahl des Servers - Kolab, SLOX (Suse Linux Open Exchange, Anm. d. Redaktion) oder eGroupware. Experimentell funktioniert auch bereits die Exchange-Anbindung, über die auch OpenGroupware angebunden werden kann.
Golem.de: Wie kann man sich die angestrebte Lösung eines wirklich integrierten Groupware-Clients vorstellen?
Molkentin: Integration bedeutet nicht nur die optionale Vereinigung in einem Programm, wie sie Kontact bietet. Schon heute sind Drittprogramme wie Kopete oder aKgregator in Kontact integriert. Im Falle von Kopete bedeutet das aber nicht, dass sich alles in einem Fenster abspielt, sondern dass die Anwendungen dort verzahnt sind, wo es dem Benutzer eine Hilfe ist. Das ist letztendlich nichts anderes als eine konsequente Fortführung der Prinzipien des KDE-Desktops auf den Kommunikationsalltag.
Golem.de: Dennoch bietet das Zusammenspiel der einzelnen Komponenten noch Optimierungspotenzial. So ist es in KDE 3.2 beispielsweise möglich, Kontakte und Aufgaben zu verbinden - von einem Kontakt zu den dazugehörigen E-Mails führt hingegen kein direkter Weg?
Molkentin: Nein, aber das ist geplant.
Golem.de: Wie gestaltet sich die Integration mit entsprechenden Server-Komponenten wie Kolab, eGroupware, OpenExchange oder OpenGroupware.org?
Molkentin: Das Kernstück der Integration ist das so genannte Ressource Framework. Eine Ressource ist etwa ein Kalender oder eine Addresssammlung. Das Framework besitzt eine Plugin-Schnittstelle, die es ermöglicht, auf diese Ressourcen über die von den Groupware Servern verstandenen Protokolle zuzugreifen.
Kontakte und Kalender liegen bei Kolab z.B. in speziellen IMAP-Ordnern, auf die direkt zugegriffen wird, während Exchange und SLOX via WebDAV kommunizieren. EGroupware hingegen verwendet XMLRPC zur Kommunikation nach außen. So lassen sich für jeden Groupware Server ganz individuelle Zugriffsmethoden entwickeln, die von Kontact aus mit einer gemeinsamen API angesprochen werden können.
Der Benutzer hingegen bekommt von den Details kaum etwas mit. Für jede von Kontact unterstüzte Groupware-Lösung gibt es einen einfachen Einrichtungsassistenten.
Golem.de: Wie steht es um eine plattformübergreifende Einbindung z.B. mit Microsoft Exchange oder Lotus Domino?
Molkentin: Durch die durch das Netzwerk und das Ressource Framework erreichte Abstraktion spielt es für uns im Grunde keine Rolle, auf welcher Plattform ein Server läuft.
Für Lotus Domino ist bislang keine Unterstützung geplant. Keiner der Entwickler arbeitet damit und es hat sich bislang niemand gemeldet, der eine Lizenz besäße. Außerdem bietet Lotus viel mehr Funktionsumfang, als Kontact derzeit abdecken kann. Dazu kommt, dass IBMs Lotus-Abteilung an einem nativen Linux Client ihrer Client-Produkte in jeder Form kein Interesse zu haben scheint.
Exchange Support steht dagegen schon lange auf unserer Liste. Viele Teile wie z.B. die Kalenderressource sind implementiert, Kalender und E-Mail funktionieren schon mit Exchange 2000. Voraussetzung ist natürlich immer ein aktiviertes OWA (Outlook Web Access, Anm. d. Red.). Es fehlt lediglich an einem Betreuer, der es in einer Exchange-Umgebung testen und entwickeln kann, um die Anbindung zu vervollständigen. Wer sich angesprochen fühlt, ist herzlich zur Mitarbeit eingeladen.
Golem.de: Mit KMail verfügt KDE seit geraumer Zeit über einen mittlerweile sehr mächtigen E-Mail-Client. In welchen Bereichen hat KMail noch Nachholebedarf?
Ingo Klöcker: Es gibt einige Dinge, die noch verbessert werden könnten, z.B. ressourcenschonender Umgang mit großen E-Mails, einfachere Erstkonfiguration, Filtern von neuer Post in IMAP-Ordnern, Unterstützung von KWallet zur Passwortspeicherung, Volltextsuche usw.
Golem.de: Spam ist heute das größte Problem für die E-Mail-Kommunikation und der "richtige" Umgang mit Spam daher auch eine der wichtigsten Herausforderungen für E-Mail-Clients. Welche Möglichkeiten zur Spam-Abwehr bietet KMail, insbesondere in Bezug auf eine Integration mit serverbasierten Anti-Spam-Werkzeugen?
Klöcker: In Bezug auf eine Integration mit serverbasierten Anti-Spam-Werkzeugen bietet KMail keine besondere Unterstützung, wobei KMail selbstverständlich als Spam markierte E-Mails ohne Probleme ausfiltern kann. Falls die Post über einen POP-Account abgerufen wird, kann man mit Hilfe von POP-Filtern als Spam markierte E-Mails direkt vom Server löschen, ohne sie erst herunterladen zu müssen.
Die Integration mit clientbasierten Anti-Spam-Werkzeugen erfolgt auf der Basis von KMails mächtigen Filterfunktionen. Seit KDE 3.2 können einzelne Filteraktionen gezielt aufgerufen werden. Dadurch ist es möglich, Anti-Spam-Werkzeuge mit Spam und Nicht-Spam zu trainieren. Neu in KDE 3.3 ist ein Wizard, der den Benutzer bei der Erstkonfiguration eines clientbasierten Anti-Spam-Werkzeugs unterstützt. Derzeit kennt der Wizard SpamAssassin, Bogofilter und Annoyance-Filter.
Golem.de: KMail bietet zahlreiche Funktionen für eine sichere E-Mail-Kommunikation, bedingt unter anderem auch durch eine gezielte Förderung durch das BSI. Dennoch wird die Verschlüsselung von E-Mails oft als umständlich empfunden und nicht genutzt. Welche Schritte sind notwendig, damit sich eine Verschlüsselung von E-Mails auf breiter Front durchsetzen kann?
Klöcker: Wenn wir das wüssten...
Eine Möglichkeit wäre die automatische Erzeugung eines Schlüsselpaares bei der ersten Benutzung eines Mail-Clients. Der Mail-Client müsste dann standardmäßig alle E-Mails zumindest schon mal signieren. Verschlüsseln ist unendlich schwieriger, da dazu der öffentliche Schlüssel des Empfängers vorliegen muss. Die Schwierigkeit dabei ist die Feststellung der Authentizität dieses Schlüssels, d.h. ob der Schlüssel tatsächlich dem Empfänger gehört. Bei der Beantwortung einer signierten E-Mail könnte man mit dem Schlüssel verschlüsseln, der auch zum Signieren verwendet wurde. Zur Vereinfachung sollte der Schlüssel an die E-Mail angehängt werden. Beim Erstellen einer neuen E-Mail könnte man aus der Kenntnis von bereits empfangenen signierten E-Mails auf den richtigen Schlüssel schließen.
Das Problem an diesem Automatismus ist aber, dass eine Überprüfung der Authentizität der Schlüssel nicht stattfindet. Es wird einfach die Authentizität von empfangenen E-Mails angenommen. Dass man der Absenderadresse aber nicht trauen kann, sollte wohl dank der zahlreichen aktuellen Viren/Würmer jedem klar sein. Insofern ist der oben beschriebene Automatismus meiner Meinung nach nicht akzeptabel. Ohne eine zentrale PKI, die meiner Meinung nach von der Bundesregierung bereitgestellt werden sollte, geht es einfach nicht.
Golem.de: Große Bestände an archivierten E-Mails stellen jedes E-Mail-Programm vor gewisse Schwierigkeiten. Zwar bietet KMail mit der Möglichkeit, Suchanfragen in virtuelle Ordner zu verwandeln, eine sehr nützliche Funktion. Die gezielte Suche nach E-Mails kann aber so manches System an seine Grenzen bringen. Darf man diesbezüglich auf Besserung hoffen?
Klöcker: Wir hoffen, bald eine indizierte Volltextsuche anbieten zu können. Weitere Verbesserungen wären durch eine weitergehende Indizierung (z.B. nach dem Absender) zu erwarten. Letzteres ist derzeit nicht in Planung.