Unterabschnitte

Mailserver-Systeme

In den bisherigen Kapiteln wurde das Common Information Model im Detail beschrieben. Da es das Ziel dieser Arbeit ist, zu bewerten, ob CIM als Framework für das generische Management von Applikationen geeignet ist, wurde recht schnell deutlich, dass nur die Implementierung eines Piloten zu tiefgreifenderen Erkenntnissen führen würde.

Voraussetzung für eine Implementierung ist jedoch zunächst ein CIM-Datenmodell -- und Voraussetzung für das Datenmodell ist ein Bereich, den es modellieren soll.

Die Suche nach einem passenden Einsatzgebiet fand sich schnell: Das Management eines Mailserver-Systems sollte modelliert werden. Gründe für diese Auswahl waren:

E-Mail hat sich in Unternehmen und Organisationen, aber auch für Privatpersonen zu einem der wichtigsten Kommunikationsmittel entwickelt. Dies bedeutet:
- Ein e-Mail-System ist in so gut wie jedem Unternehmen vorhanden.
- Insbesondere Unternehmen sind auf eine jederzeit verfügbare e-Mail-Infrastruktur angewiesen, dem Management eines Mailserver-Systems kommt also eine zentrale Bedeutung zu.
Mailserver-Systeme sind mit der restlichen IT-Infrastruktur eines Unternehmens meist hochgradig verwoben, es existiert eine Vielzahl von Abhängigkeiten.
Mailserver-Systeme unterscheiden sich oft stark in Leistungsumfang und Art der Implementierung.
Bisher existiert noch kein CIM-Schema für Mailserver-Systeme. Das entworfene Schema könnte der Allgemeinheit zur Verfügung gestellt werden.

Da untersucht werden sollte, ob mit CIM ein generisches Management verteilter Informationssysteme möglich ist, war es nötig, den Entwurf des Schemas allgemein vorzunehmen, um eine anschließende Implementierung von Providern auf mindestens zwei verschiedene Mailserver-Systeme umzusetzen.

Auch wenn eine Umsetzung auf mehr als zwei Systeme sicherlich eine noch deutlichere Aussagekraft der Untersuchung herbeigeführt hätte, fiel die Entscheidung zugunsten zweier Implementierungen, da:

der Aufwand für die zweifache Umsetzung bereits recht hoch ist
der Fokus des praktischen Teils dieser Arbeit primär auf dem zugrunde liegenden CIM-Schema liegen sollte.

Als Zielsystem sollte ein Paar verwendet werden, das sich aus konzeptioneller und konfigurationstechnischer Sicht stark unterscheidet. Eine weitere Vorgabe war der Wunsch der Thinking Objects Software GmbH, dass die Implementierung unter Linux erfolgen sollte. Die Wahl fiel daher auf die folgenden Mailserver-Systeme:

Das Open-Source-Projekt Cyrus IMAPd der Carnegie-Mellon-Universität
Die kommerzielle Lösung Contact der Samsung Software Division. Contact wurde ursprünglich von HP unter dem Namen OpenMail entwickelt und vertrieben und im Jahr 2002 an Samsung verkauft.

Cyrus IMAPd und Contact werden in den Kapiteln 6.1 bzw 6.2 in Bezug auf Architektur und Konfiguration vorgestellt, in Kapitel 6.3 findet sich anschließend eine Gegenüberstellung.

Cyrus IMAPd

Die Carnegie Mellon-Universität in Pittsburgh (USA) entwickelte den Mailserver Cyrus IMAPd seit 1994 zur eigenen Verwendung als Campus-weites Mailsystem. Seine besonderen Merkmale sind:

Das Projekt unterliegt einer Open Source-Lizenz, so dass jeder das Produkt einsetzen und für seine eigenen Bedürfnisse anpassen kann.
Der Cyrus IMAPd basiert auf offenen Standards, damit der Einsatz beliebiger Clients möglich ist:
- User-Schnittstelle: Hier werden die Protokolle IMAP und POP3 unterstützt, beide auch in einer verschlüsselten Variante (IMAPs und POP3s).
- MTA-Schnittstelle: Hier kommt das LMTP-Protokoll zum Einsatz.
- serverseitige Filterung: Dafür wurde der offene Standard Sieve entworfen, der zwischenzeitlich als RFC eingereicht wurde.
Der Server ist gut skalierbar: Er kann sowohl auf kleinen Systemen mit 5 Benutzern mit geringem Ressourcenbedarf eingesetzt werden, andererseits sind auch Umgebungen mit 30.000 Benutzern bekannt.

Architektur des Cyrus IMAPd

Eine Übersicht über die Architektur des Cyrus IMAPd liefert Abbildung 6.1.

**Abbildung 6.1:** Architektur des Cyrus IMAPd

Kern sind zwei Datenbanken:

Der Message Store enthält sämtliche Nachrichten. Diese werden in einer Filesystem-Hierarchie separiert nach Benutzer und Orderpfad gespeichert.
Die Konfigurationsdaten liegen in einem abgetrennten Bereich: Sie enthalten Informationen zu vorhandenen Benutzern, Quotas, Access Control Listen und Filterregeln

Auf diese Daten greifen die Softwarekomponenten, die für die äußere Kommunikation verantwortlich sind, direkt zu:

Der imapd nimmt Benutzeranfragen über das IMAP-Protokoll entgegen.
Der pop3d nimmt Benutzeranfragen über das POP3-Protokoll entgegen.
Der lmtpd wird durch dem MTA aufgerufen und nimmt eingehende Mail per LMTP entgegen. Falls der MTA nicht LMTP-fähig ist, kann das Programm deliver diese Funktion übernehmen.
Der timsieved wird durch sieve-Clients aufgerufen und installiert aktualisierte Filterregeln.

Konfiguration des Cyrus IMAPd

Für die Konfiguration des Servers ist keine einheitliche Strategie erkennbar, was durch sein historisches Wachstum bedingt sein dürfte.

Die initiale Konfiguration des Servicedienstes geschieht über zwei Konfigurationsdateien, nämlich /etc/imapd.conf und /etc/cyrus.conf. Darin werden beispielsweise alle Angaben bezüglich Authentifizierungsmechanismen, Datenbankpfaden und zu startende Dienste vorgenommen.
Routineaufgaben der täglichen Administration erfolgen über das IMAP-Protokoll selbst. Dazu wird die Kommandoshell cyradm mitgeliefert. Mit ihr können die folgenden Aufgaben vollzogen werden:
- Benutzerverwaltung (Anlegen, Löschen)
- Ordnerverwaltung (Anlegen, Löschen, Umbenennen)
- ACL-Verwaltung (Anlegen, Löschen, Modifizieren)
- Quota-Verwaltung (Anlegen, Löschen, Modifizieren)

Contact

Der Mailserver Contactwurde ursprünglich von HP als OpenMail entwickelt und verkauft, 2002 ging das Produkt dann in die Hände der Samsung Software Division über.

Als Betriebssysteme unterstützt Contact momentan neben die UNIX-Derivate HP-UX, Sun Solaris und IBM AIX sowie Linux. Ursprünglich wurde das System als X.400-Lösung entwickelt, später wurde es durch ein integriertes Gateway auch Internet-fähig. Da Contact den Anspruch erhebt, eine integrierte Lösung für alle Arten der elektronischen Kommunikation zu bieten, ist der Umfang reichhaltig:

Mailrouting über das Internet per SMTP oder über X.400
große Nachrichtenbank, die mehrere Terabyte umfassen kann. Der Referenzkunde BMW betreibt eine Contact-Installation mit ca. 30.000 Accounts.
Client-Schnittstellen über diverse Protokolle:
- IMAP
- POP3
- MAPI (Protokoll von Microsoft Outlook, unterstützt neben Mailhandling auch elektronische Kalender)
- Web-Interface
- WAP-Interface
- eigenes Protokoll für Samsung-Clients
Der Zugriff auf das Benutzerverzeichnis ist über LDAP möglich.
Nachrichten können an ein eigenes SMS-Gateway weitergeleitet werden.
benutzerdefinierte oder systemweite Regeln erlauben eine Filterung von Nachrichten

Architektur von Contact

Ein Ausschnitt aus der Architektur von Contact ist in Abbildung 6.2 wiedergegeben. Dargestellt sind Subsysteme, die für den Nachrichtenfluss und -zugriff verantwortlich sind.

**Abbildung 6.2:** Architektur von Contact

Im Gegensatz zum Cyrus IMAPd erfolgt der Zugriff auf die Nachrichtendatenbank (message store, unter UNIX unter /var/lib/openmail/data/) bei Contact nicht direkt durch den jeweiligen Service-Daemon, sondern über einen UAL-Agenten. Dieser besitzt eine proprietäre API, auf die der IMAP-, POP-, Web- oder WAP-Agent aufsetzt. Aufgabe des Agenten ist es jeweils, zwischen dem Client-Protokoll und einem X.400-Nachrichtenformat zu konvertieren, da der message store intern diesen Standard verwendet.

Gleiches gilt für ein- und ausgehende Mail, die über das Internet-Gateway versandt wird. Dazu sind die beiden Dienste unix.in und unix.out verantwortlich. Der service router ist intern für die Weiterleitung von Mail in den message store zuständig und kannmit anderen X.400-Systemen kommunizieren.

Konfiguration von Contact

Obwohl die Gesamtarchitektur von Contact sehr komplex ist, erfolgt die Konfiguration über ein fast durchweg orthogonales Schema: Konfigurationsänderungen werden über Kommandozeilenprogramme vorgenommen, deren Name folgendem Schema entspricht:

om<aktion><klasse>

D.h., jeder Befehl beginnt mit om (für OpenMail), gefolgt von einer Aktion, wie beispielsweise del (für Löschen), add (für Hinzufügen) oder show (für Anzeigen). Daran schließt sich eine Objektklasse an, auf die eine Aktion angewandt werden soll, wie beispielsweise u (für einen User), bb (für eine Bulletin Board Area) oder ux (für ein Internet-Gateway). Dies ermöglicht eine einfache Script-Steuerung des Mailservers-Dienstes.

Gegenüberstellung von Cyrus und Contact

In welchen Merkmalen sich die Produkte Cyrus IMAPd und Samsung Contact unterscheiden, soll in der folgenden Tabelle erläutert werden.

Tabelle 6.1: Vergleich von Cyrus IMAPd und Contact

	Cyrus IMAPd	Contact
Hersteller	CMU	Samsung SDS
Lizenz	Open Source (eigene)	kommerziell
int. Format	Internet	X.400
int. Speicherung	Filesystem	Datenbank
MTA-Protokolle	LMTP, sendmail-Mailer	SMTP, sendmail-Mailer, X.400
Client-Protkolle	IMAP(s), POP3(s)	IMAP, POP3, Web, WAP, eigenes
Konfiguration	Configfiles, IMAP	Shell-Kommandos

Fußnoten

... sollte: getreu der Erkenntnis, dass im Rahmen des Software Engineering eine gute Modellierung eine gute Implementierung erst möglich macht
... IMAPd: http://asg.web.cmu.edu/cyrus/imapd/
...MTA: Mail Transport Agent, kommuniziert mit anderen Mailservern für ein- und ausgehende Mail
...Contact: http://www.samsungcontact.com/
... vorgenommen: einige Konfigurationsänderungen müssen in entsprechenden Dateien vorgenommen werden