Apache James 3.8.0: Mailet-Container, vier Guice-Varianten und das Demo-Image mit Port 993

James 3.8.0: ein Mailserver aus Bausteinen statt aus einem Stück

Das Repository apache/james-project enthält den Apache James Server, und das README löst den Namen auf: Java Apache Mail Enterprise Server. Die Kurzbeschreibung fasst den Ansatz in einem Gedanken zusammen, der sich gut merken lässt. E-Mails sollen im Zentrum der eigenen Fachlogik stehen, und die Zusammenstellung der Bausteine bleibt dem Betreiber überlassen.

Der Ausgangspunkt ist die Erfahrung mit fertigen Mailservern. Wer Filter- und Weiterleitungsregeln anpassen will, stößt bei klassischen Servern schnell an die Grenzen von Konfigurationsdateien. James setzt auf eine modulare Architektur, bei der Protokollseite, Speicherseite und Verarbeitung getrennt sind und sich einzeln ersetzen lassen.

Die unterstützten Protokolle sind im README benannt: IMAP, SMTP, JMAP und POP3, ergänzt um ein und mehr, das die Liste offenlässt. Als aktuelle Version führt das README die Nummer 3.8.0. Die Metadaten nennen Java als Sprache sowie die Apache-Lizenz 2.0. Zum Abrufzeitpunkt standen rund 1.000 Sterne und 491 Forks im Raum, Standardbranch ist master.

Mailet-Container und umgekehrte Steuerung im James-Server

Zwei Begriffe aus dem README erklären die Arbeitsweise. Der erste ist die Umkehrung der Steuerung: James stellt eine Plattform bereit, auf der die benötigten Bestandteile zusammengesteckt werden, statt eine feste Auswahl vorzugeben. Der zweite ist der Mailet-Container, über den Filter- und Weiterleitungsregeln angepasst werden.

Für die tägliche Arbeit wiegt der zweite Begriff schwerer. Er erlaubt, Verarbeitungsschritte als eigene Einheiten einzuhängen, die über die Zustellung hinausgehen, etwa Prüfung von Anhängen, Ablegen in Fachsysteme oder Anreichern von Kopfzeilen. Das README nennt diese Möglichkeit ausdrücklich als Weg über die reine Konfiguration hinaus und stellt sie als Kern des Ansatzes dar.

Was das README nicht liefert, ist ein Beispiel für eine solche Regel. Es verweist auf das Verzeichnis examples/README.md für eigenen Code sowie auf die Dokumentation und auf Architekturentscheidungen, die in einem eigenen Verzeichnis liegen. Wer die Schnittstelle der Mailets bewerten will, muss dort weiterlesen und findet im Repository selbst keine Vorlage.

docker run apache/james:demo-3.8.0 mit IMAPS 993 und SMTPS 465

Der schnellste Weg zum ersten Eindruck führt über ein Container-Image. Als Voraussetzung nennt das README eine vorhandene Docker-Installation, und der Aufruf besteht aus einer einzigen Zeile: docker run -p "465:465" -p "993:993" apache/james:demo-3.8.0.

Das Bild bringt eine Standardkonfiguration mit, die auf JPA mit hsqldb sowie auf Lucene setzt. Es enthält eine Standarddomäne namens james.local und drei Benutzer, user01@james.local, user02@james.local und user03@james.local, jeweils mit dem Kennwort 1234. Der Server antwortet verschlüsselt auf Port 993 für IMAPS und auf Port 465 für SMTPS. Als Client für den ersten Kontakt nennt das README ausdrücklich Thunderbird.

Diese Bequemlichkeit verlangt Vorsicht. Ein Bild mit festen Benutzern und einem Kennwort aus vier Ziffern ist ein Ausprobierbild und kein Betriebsbild. Für den nächsten Schritt verweist das README auf ein Tutorial zur Anlage eigener Benutzer und Domänen, und für Installationen ohne Container auf eine eigene Seite unter james.apache.org.

memory-app, jpa-app, cassandra-app und distributed-app im Vergleich

Für den Betrieb unterhält das Projekt laut README vier auf Guice aufgebaute Anwendungen. Die kleinste heißt memory-app, arbeitet mit Speicher im Hauptspeicher und ist ausdrücklich für Tests gedacht. Darüber liegt jpa-app mit JPA und Lucene, also jener Variante, die auch das Ausprobierbild verwendet.

Die dritte Anwendung trägt den Namen cassandra-app und verbindet Cassandra mit OpenSearch. Die vierte, distributed-app, ergänzt den Aufbau um RabbitMQ und S3 und richtet sich an skalierbare Installationen. Das README beschreibt den verteilten Server als leicht zu betreiben und nennt Cassandra, S3, OpenSearch und RabbitMQ als technische Grundlage.

Diese Abstufung ist praktisch, weil sie einen Weg vom Ausprobieren bis zum verteilten Betrieb beschreibt, ohne einen Wechsel der Software zu verlangen. Sie hat eine Kehrseite: Vier Varianten bedeuten vier Kombinationen, die gepflegt und getestet werden müssen. Welche davon den geringsten Wartungsaufwand hat und wie sich die Varianten im Verhalten unterscheiden, sagt das README nicht.

mvn clean install mit -T 4 und -DskipTests unter JDK 11

Der Bau aus den Quellen verlangt Maven ab Version 3.6.1 und, wie das README im Abschnitt zum Entwickeln präzisiert, mindestens JDK 11. Zunächst wird mit git clone git@github.com:apache/james-project.git der Quellstand geholt, anschließend genügt mvn clean install im betreffenden Verzeichnis.

Drei Optionen hebt das README hervor. -DskipTests lässt die Testsuite aus, die als langlaufend und ressourcenhungrig beschrieben wird und einen Docker-Dämon voraussetzt. -T 4 verteilt den Bau auf mehrere Prozessoren, und -Dmaven.javadoc.skip=true unterdrückt die Erzeugung der Programmdokumentation.

Die Beschreibung der Testsuite ist aufschlussreich. Wer ohne Docker-Dämon baut, überspringt damit nicht nur langsame Tests, sondern einen Teil der Absicherung. Für eine belastbare Aussage über einen eigenen Änderungsstand ist ein vollständiger Lauf nötig. Ergänzend weist das README darauf hin, dass Teile des Projekts in Scala geschrieben sind, weshalb im Editor unter Umständen eine Erweiterung aktiviert werden muss.

James gegen Postfix und Dovecot: Verarbeitung als Trennlinie

Die auffälligste Lücke betrifft die Veröffentlichung. Im Repository auf GitHub sind keine Releases hinterlegt, und eine Angabe zur letzten Aktivität am Quellstand fehlt. Veröffentlichungen laufen offenbar über die Download-Seite unter james.apache.org/download.cgi, auf die das README verweist; die dort geführte Fassung deckt sich mit der im README genannten Nummer 3.8.0.

Als Alternative bietet sich die klassische Kombination aus Postfix für den Versand und Dovecot für den Postfachzugriff an. Beide Programme sind auf ihre Aufgabe spezialisiert und in vielen Umgebungen erprobt, verlangen aber für jede Anpassung der Verarbeitung eigene Werkzeuge oder Skripte außerhalb des Mailservers. James bündelt Protokolle, Speicher und Verarbeitung in einer Anwendung auf der JVM und öffnet die Verarbeitung über den Mailet-Container. Das trägt, wenn E-Mail Teil einer Fachanwendung ist, und ist aufwendig, wenn nur Postfächer gebraucht werden.

Die Apache-Lizenz 2.0 erlaubt den kommerziellen Einsatz einschließlich eigener Erweiterungen bei Beachtung der Hinweispflichten; eine Gewährleistung ist ausgeschlossen. Hinzu kommen beim Betrieb von E-Mail-Infrastruktur Anforderungen, die kein README abdecken, etwa Zustellbarkeit, Spam-Behandlung und Aufbewahrungsfristen.

Redaktionelles Fazit

James passt zu Vorhaben, bei denen E-Mail-Verarbeitung Teil der eigenen Fachlogik ist und Filter- oder Weiterleitungsregeln über den Mailet-Container selbst geschrieben werden sollen. Wer lediglich Postfächer und Versand braucht, ist mit Postfix und Dovecot auf schmalerer Grundlage unterwegs. Vor dem Einsatz sollte das Demo-Image apache/james:demo-3.8.0 nur zum Ausprobieren dienen, wegen der festen Benutzer mit dem Kennwort 1234, und der produktive Aufbau über jpa-app oder distributed-app mit eigenen Domänen erfolgen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository