Apache James: modularer Mailserver und Mailet-Plattform

Apache James ist ein quelloffener Mailserver und zugleich ein Baukasten für Anwendungen, deren Geschäftslogik auf E-Mail beruht. Der Name steht für Java Apache Mail Enterprise Server. James kann Nachrichten per SMTP annehmen und weiterleiten, lokale Postfächer führen, diese über IMAP, POP3 oder JMAP bereitstellen und den gesamten Nachrichtenfluss durch frei kombinierbare Verarbeitungskomponenten steuern. Das Projekt beschreibt sich deshalb nicht nur als Server, sondern als modular zusammensetzbare Inversion-of-Control-Plattform auf der JVM (Apache James – Projektübersicht).

Diese Doppelrolle unterscheidet James von klassischen Mail Transfer Agents wie Postfix und von fertigen Security-Appliances. Ein Administrator kann James als reines SMTP-Relay betreiben, als vollständigen Mailbox-Server oder als eingebettete Mail-Engine eines Produkts. Spamprüfung, Verschlüsselung, Archivierung oder domänenspezifisches Routing entstehen dabei nicht aus einem starren Funktionsblock, sondern aus einer Pipeline von Matchers und Mailets. Das macht James aussergewöhnlich anpassbar, verlagert aber einen Teil der Produktverantwortung vom Hersteller auf die betreibende Organisation.

Die Erklärung folgt einer Nachricht durch James: von den Protokollservern über Queue und Mailet-Pipeline bis zum Postfachspeicher. Darauf bauen die Betriebsvarianten, die Diagnose und schliesslich die technische Entwicklung des Projekts auf.

Einordnung: MTA, MDA und Anwendungsplattform

Im E-Mail-System übernimmt nicht jede Komponente dieselbe Rolle. Ein Mail User Agent (MUA) ist der Client des Benutzers, etwa Thunderbird. Ein Mail Transfer Agent (MTA) transportiert Nachrichten zwischen Systemen. Ein Mail Delivery Agent (MDA) legt eine Nachricht im Zielpostfach ab. James kann MTA und MDA zugleich sein; über seine Protokoll- und Mailbox-Module stellt es zusätzlich serverseitige Dienste für MUAs bereit. Die offizielle Komponentenübersicht nennt dafür getrennte Projekte für Server, Protokolle, Mailets, Mailboxen und Tests (Apache James – Software Components).

James ist damit kein Mailclient und auch kein vorkonfiguriertes Secure-Mail-Gateway. Es liefert Bausteine für Transport, Zustellung, Speicherung und Verarbeitung. Ob daraus ein einfacher Relay, ein mandantenfähiger Maildienst oder ein produktspezifisches Gateway entsteht, entscheidet die gewählte Distribution und Konfiguration.

Protokolle, TLS und Ports

James stellt SMTP, LMTP, IMAP, POP3 und ManageSieve als TCP-basierte Dienste bereit; JMAP und WebAdmin verwenden HTTP (Apache James – Protocol Servers). TLS schützt je nach Listener eine von Beginn an verschlüsselte Verbindung oder wird per StartTLS in eine bestehende Sitzung eingeschoben. DNS gehört nicht zum James-Prozess, ist für einen öffentlichen MTA aber unverzichtbar: MX-Records bestimmen das Ziel, A- und AAAA-Records dessen Adressen und PTR-Records beeinflussen die Reputation ausgehender Verbindungen.

Die Portnummer allein beschreibt noch nicht die Sicherheitssemantik. Port 25 ist für den Server-zu-Server-Transport bestimmt; die authentisierte Einlieferung durch Clients gehört nach RFC 6409 auf Port 587. Port 465 ist seit RFC 8314 wieder für implizit verschlüsseltes Message Submission registriert. Für IMAP und POP3 gelten dieselben zwei Muster: Klartextverbindung mit möglichem StartTLS oder sofortiger TLS-Aufbau.

Die Ports sind konfigurierbar; verbindlich ist die Kombination aus Listener, Protokoll, TLS-Modus und Authentisierung. Die IANA Service Name and Port Number Registry bleibt die Referenz für registrierte Zuordnungen.

Architekturansatz

James folgt einer komponentenbasierten Architektur. Protokollserver, Queue, Verarbeitungslogik, Mailbox, Benutzerverwaltung, Suchindex und Administration sind über APIs voneinander getrennt und werden durch Dependency Injection zusammengesetzt. Die für James 3.9 dokumentierten Distributionen setzen dafür auf Google Guice; der Spring-Aufbau gehört zu einer älteren Generation. Die Entkopplung ist nicht bloss eine Code-Organisation: Sie erlaubt, dieselbe Mailbox API mit unterschiedlichen Persistenzschichten und dieselbe Mailet-Logik in sehr verschiedenen Serverprofilen zu verwenden.

Der zentrale Datenpfad ist asynchron. Ein SMTP-Listener muss eine angenommene Nachricht nicht vollständig zustellen, bevor er die Verbindung beantwortet. Er legt ein Mail-Objekt in eine Queue; ein Spooler entnimmt es später und führt es durch den Mailet-Container. Die Queue trennt damit Empfangslast, Verarbeitungszeit und die Verfügbarkeit nachgelagerter Systeme. Die verteilte Betriebsdokumentation bezeichnet sie folgerichtig als obligatorischen Bestandteil eines SMTP-Servers (Apache James – Distributed Server Operations).

Der Verarbeitungsweg einer Nachricht

1. Protokollannahme: SMTP oder LMTP prüft Sitzung, Authentisierung, Envelope-Absender und Empfänger. Nach dem Ende von DATA entsteht ein internes Mail-Objekt mit Envelope, MIME-Inhalt und Attributen.
2. Queue: Das Objekt wird dauerhaft oder flüchtig eingereiht. Erst ab diesem Punkt ist Annahme von Verarbeitung entkoppelt.
3. Spooler: Worker entnehmen Queue-Einträge und übergeben sie an den Mailet-Container.
4. Processor: Ein benannter Processor enthält eine geordnete Liste aus Matcher/Mailet-Paaren. Der obligatorische root-Processor bildet den Einstieg.
5. Matcher: Ein Matcher verändert die Nachricht nicht, sondern liefert die Teilmenge der Empfänger zurück, für die eine Bedingung gilt.
6. Mailet: Das zugehörige Mailet verändert Nachricht oder Envelope, löst eine Nebenwirkung aus, stellt lokal oder entfernt zu oder verzweigt in einen anderen Processor.
7. Ergebnis: Die Nachricht landet in einem Benutzerpostfach, in der ausgehenden Zustellung, in einem Mail Repository für spätere Behandlung oder ist nach erfolgreicher Aktion abgeschlossen.

Ein wichtiges Detail ist der empfängerbezogene Split. Passt ein Matcher nur auf einen Teil der Adressaten, teilt der Container die Verarbeitung in passende und nicht passende Empfängermengen. Regeln gelten daher nicht zwangsläufig für eine komplette MIME-Nachricht. Ein Mailet kann zudem per ToProcessor unmittelbar in einen anderen Processor springen; die Pipeline ist damit eher ein gerichteter Verarbeitungsgraph als eine einzige lineare Liste. Die offizielle Mailet-Container-Dokumentation beschreibt genau dieses Modell.

Ein minimales, vereinfachtes Muster sieht so aus:

<processor state="root" enableJmx="true">
  <mailet match="RelayLimit=30" class="ToRepository">
    <repositoryPath>cassandra://var/mail/relay-denied/</repositoryPath>
  </mailet>
  <mailet match="RecipientIsLocal" class="LocalDelivery" />
  <mailet match="All" class="RemoteDelivery" />
</processor>

Die Reihenfolge ist Teil der Semantik. Eine breit passende Regel am Anfang kann nachfolgende Regeln unerreichbar machen; eine Endlosschleife zwischen Processors kann den Spooler binden. James bietet deshalb pro Matcher und Mailet definierbares Fehlerverhalten sowie eigene Fehler-Processors (Mailet Container Configuration).

Die Komponentenarchitektur wird konkret, sobald eine Nachricht die Queue erreicht. Dann bestimmen Processor, Matcher und Mailet, welche Verarbeitungsschritte folgen und wohin das Ergebnis gelangt.

Technischer Aufbau

Die Architektur beschreibt den Nachrichtenweg; für Installation und Betrieb muss daraus nun ein konkretes Komponentenbild werden. Entscheidend ist, welche Laufzeit, Speicher und Zusatzdienste das gewählte James-Profil tatsächlich benötigt.

Technologiestack und Admin-Überblick

Für die erste Produkteinordnung sind weniger Klassennamen als die Betriebsgrenzen entscheidend. Die folgende Übersicht verdichtet den Stack auf die Fragen, die vor Installation, Integration oder Übernahme einer bestehenden Umgebung geklärt sein sollten:

Alle Konfigurationsdateien liegen laut Projekt in conf beziehungsweise conf/META-INF; welche davon tatsächlich gelten, hängt vom Wiring und Backend ab. Werte können mit ${env:VARIABLE} aus der Umgebung bezogen werden (Apache James – Configuration). Das ist für Container praktisch, ersetzt aber kein Secret-Management: Zertifikate, private Schlüssel, JWT-Schlüssel und Datenbankpasswörter sollten als gemountete Secrets oder über die Orchestrierungsplattform bereitgestellt werden.

Protokollschicht

Das Protocols-Projekt stellt erweiterbare Serverimplementierungen für SMTP, LMTP, IMAP, POP3, ManageSieve und JMAP bereit (James Protocols). Die Listener sind nicht fest mit einer bestimmten Speicherung verdrahtet. IMAP und JMAP greifen über die Mailbox API zu; SMTP übergibt angenommene Nachrichten an Queue und Mailet-Container. Dadurch können Protokolle unabhängig von der Backend-Topologie skaliert oder deaktiviert werden.

Mailbox, Mail Repository und Blob-Speicher

James unterscheidet drei Speicherbegriffe, die im Betrieb nicht vermischt werden sollten:

Die Persistenzdokumentation betont, dass ein Mail Repository gerade nicht das Benutzerpostfach ist. Diese Trennung ist für Incident Response wertvoll: Eine fehlerhafte Nachricht kann isoliert, untersucht und nach einer Korrektur erneut in die Pipeline gegeben werden, ohne das Postfachmodell zu umgehen.

Ereignisbus, Suche und Projektionen

Mailbox-Operationen erzeugen Ereignisse, etwa MailboxAdded, MessageMoveEvent, FlagsUpdated oder Quota-Änderungen. Listener aktualisieren daraus Quotas, Suchindizes und weitere Projektionen. Im verteilten Profil übernimmt RabbitMQ die Kommunikation, OpenSearch die Suche und Cassandra die Metadaten; binäre Inhalte liegen in einem S3-kompatiblen Object Store. Diese Zerlegung ermöglicht horizontale Skalierung, erzeugt aber eventuelle Konsistenz zwischen Quelle und Projektionen. Fehlgeschlagene Listener-Ereignisse landen in einem Event Dead Letter und müssen überwacht und gegebenenfalls erneut zugestellt werden (Distributed James – Mailbox Event Bus).

MIME, Sieve und Authentisierung von Absendern

Das James-Projekt umfasst mehr als den Server. Apache Mime4J parst MIME-Strukturen streamorientiert oder als Objektmodell; jSieve implementiert die Sieve-Filtersprache; jSPF und jDKIM stellen Java-Bibliotheken für Absenderprüfung beziehungsweise DKIM-Signatur und -Verifikation bereit. Diese Module sind eigenständige Projekte und können auch ausserhalb eines vollständigen James-Servers verwendet werden (Apache James – Komponenten).

Welche dieser Komponenten auf einem Knoten oder verteilt laufen, ist keine reine Performancefrage. Die Wahl legt auch Konsistenz, Wiederanlauf und die Zahl der zu überwachenden Backends fest.

Betriebsvarianten und Skalierung

Für James 3.9.0 dokumentiert Apache mehrere Profile. Es handelt sich nicht um bloss unterschiedliche Installer, sondern um verschiedene Konsistenz-, Skalierungs- und Betriebsmodelle. In diesem Stand ist die JPA-Variante ausdrücklich als legacy bezeichnet; daneben stehen eine PostgreSQL- sowie eine verteilte Distribution (Apache James – Downloads). Die in der Grafik als Betriebsableitung bezeichneten Punkte sind daraus abgeleitete Empfehlungen und keine wörtlichen Herstellerangaben.

Die 3.9-Veröffentlichung hebt die leistungsfähige PostgreSQL-Implementierung als wesentliche Neuerung hervor und beschreibt sie als sowohl standalone-fähig als auch durch RabbitMQ, OpenSearch und S3 skalierbar (Apache James 3.9.0). Für neue Installationen ist dies meist der verständlichste Ausgangspunkt: erst relationale Konsistenz und bekannte Sicherungsverfahren, dann zusätzliche Dienste nur für konkret gemessene Anforderungen.

Sicherheitsmodell

James stellt TLS, SMTP-Authentisierung, Protokollkontrollen und kryptografische Mailets bereit. Daraus folgt jedoch nicht automatisch ein sicherer Produktionsbetrieb. Transportverschlüsselung schützt einen Hop; sie ersetzt weder Ende-zu-Ende-Verschlüsselung noch eine verbindliche Empfängerprüfung. Die TLS-Konfiguration trennt Keystore, aktivierte Cipher Suites, StartTLS und implizites TLS je Listener. Ein Zertifikatswechsel muss deshalb für SMTP, IMAP, POP3 und HTTP getrennt nachvollzogen werden.

Besondere Aufmerksamkeit verdient WebAdmin. Die REST-API kann Domains, Benutzer, Mailboxen, Queues, Repositories, Quotas und Wartungstasks verändern. Laut WebAdmin-Dokumentation ist JWT-Authentisierung standardmässig deaktiviert; ohne zusätzliche Absicherung darf die API daher niemals aus einem unkontrollierten Netz erreichbar sein. Gesundheitsendpunkte und API-Dokumentation können zudem bewusst ausserhalb der Authentisierung liegen.

Eine minimale Produktionshärtung umfasst:

• WebAdmin an ein Managementnetz binden, JWT aktivieren und den Zugriff zusätzlich durch Firewall oder Reverse Proxy begrenzen;
• offene Relays durch explizite Relay-, Authentisierungs- und Empfängerregeln verhindern;
• Submission und Server-zu-Server-SMTP auf getrennten Listenern mit unterschiedlichen Policies betreiben;
• Demo-Domains, Beispielbenutzer und Standardpasswörter aus Container-Images vor dem ersten externen Start entfernen;
• private Schlüssel ausserhalb des Container-Layers verwalten und Ablaufdaten überwachen;
• benutzerdefinierte Mailets wie Anwendungscode behandeln: Abhängigkeiten prüfen, Tests ausführen und Laufzeitrechte begrenzen;
• Spam- und Malwareprüfung bewusst entwerfen. James ist eine Plattform; externe Scanner und Reputation-Dienste werden über Mailets oder Protokollübergaben eingebunden.

Für die Fehlersuche wird der Nachrichtenweg wieder in derselben Reihenfolge geprüft: Listener, Queue, Mailet-Pipeline, Repository, Mailbox und ausgehende Zustellung.

Betrieb und Fehlersuche

Bei einem modularen Mailserver ist «der Dienst läuft» keine hinreichende Zustandsaussage. Die WebAdmin-Health-Checks unterscheiden healthy, degraded und unhealthy; im strikten Modus führt bereits ein degradierter Bestandteil zu HTTP 503. Geprüft werden je nach Profil unter anderem JPA oder Cassandra, OpenSearch, RabbitMQ, der Guice-Lebenszyklus, Event Dead Letters und eine vollständige Testzustellung (WebAdmin Health Checks).

Für die Diagnose ist ein schichtweiser Weg effizienter als eine globale Logsuche:

1. Verbindung: Erreicht der Client den richtigen Listener, und gelingt TLS mit erwartetem Zertifikat und Hostnamen?
2. SMTP-Transaktion: Welcher Antwortcode wurde für MAIL FROM, RCPT TO und DATA geliefert? Ein 250 nach DATA bedeutet Annahme, nicht zwingend Endzustellung.
3. Queue: Wächst die Zahl wartender Einträge, steigt deren Alter oder wiederholt sich derselbe Remote-Fehler?
4. Mailet-Pipeline: Welcher Processor und welches Matcher/Mailet-Paar bearbeitete die Nachricht? Die Mail-ID dient als Korrelationsschlüssel.
5. Repository: Liegt die Nachricht in error, address-error, relay-denied oder einem eigenen Repository? Erst Ursache beheben, dann reprocessen.
6. Mailbox und Ereignisse: Ist die Nachricht im führenden Mailbox-Store vorhanden, fehlt aber im Suchindex oder JMAP? Dann sind Listener, Dead Letters und Reindexierung relevanter als SMTP.
7. Remote Delivery: Bei ausgehender Zustellung DNS, Route, TLS, Gegenstellen-Code, Retry-Plan und Bounce-Erzeugung getrennt prüfen.

Ein kompakter synthetischer Check kann die Administrations- und Datenebene verbinden:

$headers = @{ Authorization = "Bearer $env:JAMES_ADMIN_JWT" }
Invoke-RestMethod `
  -Uri "https://james-admin.example.net/healthcheck?strict" `
  -Headers $headers

curl --fail --silent \
  -H "Authorization: Bearer $JAMES_ADMIN_JWT" \
  "https://james-admin.example.net/healthcheck?strict"

Unter Windows ruft Invoke-RestMethod den REST-Endpunkt auf; unter Linux und Unix übernimmt curl dieselbe HTTP-Prüfung. Beide Befehle testen hier ausschliesslich den dokumentierten WebAdmin-Health-Check und ersetzen keine synthetische SMTP- oder Mailboxtransaktion.

Zusätzlich sollten mindestens Queue-Tiefe und -Alter, Fehler-Repositories, Event Dead Letters, OpenSearch-Indexierungsrückstand, Backend-Latenzen, SMTP-Antwortklassen, JVM-Speicher und Zertifikatslaufzeiten alarmiert werden. In der verteilten Variante ist ein grüner James-Prozess bei gestörtem RabbitMQ oder OpenSearch nur ein Teilerfolg.

Werkzeuge für den Admin-Arbeitsplatz

James bringt einen Kommandozeilenclient für Domains, Benutzer, Mailboxen, Mappings, Quotas und Reindexierung mit; in Guice-Containern steht er als james-cli bereit (James CLI). Für eine belastbare Diagnose gehören daneben einige protokollneutrale Werkzeuge auf den Admin-Arbeitsplatz:

Die native Metrikdokumentation listet unter anderem aktive SMTP-, IMAP- und LMTP-Verbindungen, Queue-Einträge, gesendete und zugestellte Nachrichten, Antwortzeiten je Protokoll sowie Laufzeiten einzelner Mailets und Matchers. Diese Metriken sind aussagekräftiger als eine einzige Prozess-Uptime, weil sie den Weg einer Nachricht durch die Architektur abbilden.

Technische Geschichte

James entstand nicht als Port eines bestehenden Unix-MTAs. Die ältesten erhaltenen Projektseiten aus 1997/1998 beschreiben zunächst einen geplanten, noch nicht benutzbaren Java-Server auf Basis gemeinsamer Pakete des Java Apache Project. Vorgesehen waren gemeinsame Protokollschnittstelle, JDBC-Speicher und eine an Servlets angelehnte MailServlet-Schnittstelle; als technische Vorarbeit diente die Infrastruktur des Apache-JServ-Umfelds (James-1.0-Archiv). Die spätere Mailet API bewahrte die Grundidee kleiner, deploybarer Verarbeitungskomponenten, ohne Teil der Java-Servlet-Spezifikation zu werden.

Der Quellcode liegt im offiziellen Repository apache/james-project. Die hier betrachtete 3.9-Generation besteht überwiegend aus Java; einzelne Module verwenden Scala. Gebaut wird als grosses Maven-Multimodulprojekt. Die lange Entwicklungsgeschichte erklärt, warum in Dokumentation und Installationen mehrere Generationen nebeneinander sichtbar sind: Phoenix- und Spring-Begriffe in älteren Texten, Guice in der 3.x-Dokumentation, JPA als Legacy-Pfad und PostgreSQL- beziehungsweise Cassandra-Profile für verteilte Deployments.

Eignung und Grenzen

James ist besonders geeignet, wenn E-Mail Teil einer Anwendung statt nur Infrastruktur ist: regelbasierte Verarbeitung, eigene Mailets, offene Protokolle, JMAP, kontrollierbare Datenhaltung oder horizontale Skalierung ohne proprietären Serverkern. Die öffentlichen APIs erlauben, Transport, Mailbox und Geschäftslogik getrennt weiterzuentwickeln.

Weniger geeignet ist James für Organisationen, die eine schlüsselfertige Appliance mit vollständiger GUI, vorkonfigurierter Spam- und Malwareabwehr, Hersteller-SLAs und einem einzigen Backup-Objekt erwarten. Die modulare Freiheit erzeugt Integrationsarbeit. Besonders das verteilte Profil verlangt Betriebserfahrung mit mehreren Datensystemen und eine klare Definition von Quelle, Projektion, Wiederaufbau und Recovery Point.

Die entscheidende Architekturfrage lautet daher: Soll E-Mail als konfigurierbares Protokollsystem oder als fertiges Produkt betrieben werden? Für den ersten Fall liefert James einen ungewöhnlich tiefen, offenen Baukasten. Für den zweiten Fall ist ein stärker vorkonfiguriertes Produkt häufig wirtschaftlicher.