27. Oktober 2026Stalwart Labs · NetzwerkeKuratiert

Stalwart 1.0: Der Mailserver in Rust wird stabil und verlangt einen letzten Umzug

Zusammenfassung

Stalwart Labs kündigt im Blogbeitrag seines Projektbetreuers die Version 1.0 des in Rust geschriebenen Mail- und Kollaborationsservers an, fünf Jahre nach dem ersten Commit. Schwerpunkte sind ein endgültiges Datenbankschema, das künftige Updates ohne Datenumzug erlauben soll, und eine Leistungsoffensive mit neu geschriebenen Parsern, weniger Datenbankzugriffen und einer neuen Volltextsuche. Der Beitrag zeigt, was Betreiber beim Umstieg von 0.16 prüfen müssen, wie belastbar der Vergleich mit Postfix und Dovecot ist und warum das Projekt seine Tests nicht mehr veröffentlicht.

Version 1.0 heißt: ein letzter Umzug

Stalwart bündelt SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV und WebDAV samt Spamfilter und Clusterbetrieb in einem Programm. Die Community-Ausgabe steht unter der AGPL-3.0, eine kommerzielle Enterprise-Ausgabe ergänzt Funktionen. Begonnen hat alles am 3. Oktober 2021 mit der Rust-Bibliothek mail-parser.

Für Betreiber ist die wichtigste Nachricht keine neue Funktion: Version 1.0 nutzt ein neues Datenbanklayout und öffnet keinen Speicher einer früheren Version. Ein Austausch der Programmdatei genügt deshalb nicht. Rund hundert Konfigurationsschlüssel wurden umbenannt, einige Objekte (OIDC-Verzeichnisse, KI-Modelle, Azure-Speicher, weitergeleitete Header) neu gegliedert. Das Projekt verspricht, dass dies der letzte Umzug dieser Art ist und spätere Versionen an Ort und Stelle aktualisieren.

Für 0.16-Installationen gibt es das Werkzeug stalwart-migrate. Es setzt 0.16.27 voraus, übersetzt die Einstellungen und kopiert alle Daten in einen neuen, leeren Speicher; den alten liest es nur. Die erste Kopie läuft im Betrieb, weitere Läufe übernehmen nur Änderungen, und erst der letzte kurze Lauf braucht den gestoppten Altserver. Konto- und Nachrichtenkennungen, IMAP-UIDs und Änderungshistorie bleiben erhalten, Clients laden also nichts neu. OAuth-Nutzer melden sich neu an, der Volltextindex baut sich im Hintergrund neu auf.

Wer 0.15 oder älter betreibt oder Konten einzeln umziehen will, nutzt den Migrationsproxy und das Werkzeug Vandelay: Der Proxy leitet jeden Nutzer zum Server, der sein Konto hält, umgeschaltet wird pro Konto über einen Eintrag in einer Zuordnungstabelle. Derselbe Weg soll auch einen Umzug von Postfix und Dovecot zu Stalwart tragen.

Vor dem Upgrade prüfen

Cluster brauchen künftig einen Redis-basierten In-Memory-Speicher (Redis, Redis Cluster oder Sentinel); der Rückgriff auf den Datenspeicher entfällt. Einzelserver erhalten stattdessen einen eingebauten lokalen Speicher.

Stalwart setzt jetzt das „OAuth Profile for Open Public Clients“ vollständig durch, einen noch entstehenden Standard, mit dem sich jeder Mailclient ohne vorherige Registrierung per OAuth an jedem Mailserver anmelden kann. Viele externe Identitätsanbieter erfüllen ihn noch nicht, etwa bei der dynamischen Client-Registrierung. Kompatibilitätseinstellungen am OIDC-Verzeichnis lockern einzelne Prüfungen auf eigenes Risiko, ersetzen aber keinen Anbieter, dem das Profil fehlt. Laut Projekt übernehmen verbreitete Clients wie Apple Mail das Profil; deren Nutzer könnten sich dann an nicht konformen Anbietern nicht mehr anmelden.

Die Weboberfläche meldet sich beim Identitätsanbieter nicht mehr mit fester Client-ID, sondern über ein Client ID Metadata Document an. Unterstützt der Anbieter das nicht, registriert man dort einen Client und trägt dessen ID in oauthClientId ein.

Woher die Geschwindigkeit kommt

Ein Mailserver sucht ständig nach einzelnen Bytes: Zeilenende im Header, MIME-Grenze, Gleichheitszeichen in Quoted-Printable. mail-parser 1.0 wurde dafür neu geschrieben und nutzt SIMD, also die breiten Vektorregister (SSE2, SSSE3, AVX2, NEON), die 16 oder 32 Bytes mit einem Befehl vergleichen. Wo das nicht passt, arbeitet SWAR: Mit wenigen Rechen- und Bitoperationen prüft ein gewöhnliches 64-Bit-Register acht Bytes gleichzeitig, ganz ohne Spezialbefehle. Der passende Kern wird zur Laufzeit gewählt und jeder per Fuzzing gegen eine einfache Referenz geprüft. Die neue Bibliothek encodify übernimmt Base64, Base32, Quoted-Printable und IMAP-UTF-7.

Auf der Speicherseite vergibt Stalwart Kennungen in derselben Schreibtransaktion, die sie nutzt, und spart so ganze Rundreisen je zugestellter Nachricht. Objekte werden mit zstd und auf Mail-, Kalender- und Kontaktdaten trainierten Wörterbüchern komprimiert, jedes Backend (RocksDB, PostgreSQL, MySQL, FoundationDB, SQLite) einzeln abgestimmt. Ein neuer Cache hält den Nachrichtenindex jedes Kontos kompakt im Speicher, sodass Sortieren, Threading und Flag-Abfragen per IMAP kaum noch die Datenbank brauchen.

Die Volltextsuche speichert nun Wortpositionen und beherrscht damit echte Phrasensuche. Sie indexiert auch Text aus PDF-, Office-, OpenDocument-, EPUB- und RTF-Dateien, in Anhängen wie in der Dateiablage, mit einem eigenen Extraktor in Rust und festen Grenzen für Größe und Komplexität, damit präparierte Dateien den Server nicht erschöpfen.

Den Vergleich mit Postfix und Dovecot richtig lesen

Stalwart trat auf identischen Azure-Servern (8 vCPU AMD EPYC Zen 5, 32 GiB RAM, lokale NVMe) gegen Postfix 3.11.7 und Dovecot 2.4.5 an und lag in 35 von 38 Hauptvergleichen vorn. Eine Volltextsuche über 250.000 Nachrichten dauerte 3,75 statt 136 ms. Die drei Siege von Dovecot betreffen alle dieselbe Operation: alle Nachrichten eines Ordners auf einmal als gelesen markieren.

Das Benchmark-Repository legt Skripte, Rohdaten und eine Liste von Einschränkungen offen, und die ist lesenswert: Postfix schreibt jede eingehende Nachricht per fsync auf die Platte, bevor es sie bestätigt, Stalwart und Dovecot in der getesteten Konfiguration nicht. Stalwart ist für die genaue CPU übersetzt, Postfix und Dovecot sind Standardbuilds. Getestet wurde mit erzeugten statt echten Mails und ohne Replikation.

Tests nur noch privat

Zehn Tage vor dem Release hat das Projekt seine Testsuiten in ein privates Repository verschoben; neue Funktionen entstehen nicht mehr öffentlich und erscheinen fertig in einem einzigen Commit. Der Quellcode jeder Version bleibt unter der AGPL-3.0 öffentlich und soll sich ohne die Tests bauen lassen.

Die Begründung: KI-Agenten können vorhandene Software nachbauen, und eine umfangreiche Testsuite dient ihnen als Lösungsschlüssel, gegen den sie so lange Code erzeugen, bis alles grün ist. Stalwart berichtet von Cloud-Anbietern, die mit einer Neufassung unter MIT-Lizenz gedroht haben, um die AGPL-Pflichten loszuwerden. Eine Lizenz wie PolyForm Shield hat das Projekt erwogen und ausdrücklich verworfen, weil sie nicht quelloffen im Sinne der Open Source Definition ist. Als Vorbild nennt es SQLite, dessen gründlichste Testsuite TH3 nie veröffentlicht wurde.

Ideen

Ein stabiles Datenbankschema ist für Betreiber wertvoller als jede neue Funktion.
Inkrementelle Migration hält den alten Server bis zur letzten Minute als Rückweg bereit.
SWAR prüft acht Bytes pro Register und braucht keine besonderen Prozessorbefehle.
Ein Nachrichtenindex im Speicher erspart IMAP-Abfragen den Weg zur Datenbank.
Volltextsuche in Anhängen braucht harte Grenzen gegen präparierte Dokumente.
Herstellerbenchmarks taugen nur zusammen mit ihrer Liste der Einschränkungen.
Eine Testsuite beschreibt Jahre an Randfällen und wird damit selbst zum schützenswerten Wissen.

Einsichten

Mit 1.0 verspricht das Projekt vor allem Ruhe im Betrieb: Der Umzug wird einmal teuer bezahlt, danach soll ein Update wieder nur ein Update sein. Ob das hält, zeigt erst die nächste größere Version.
Die schnellsten Stellen eines Mailservers sind unspektakulär: Bytes suchen, Datenbankrundreisen sparen, Ergebnisse im Speicher halten. Wer das konsequent misst, gewinnt mehr als mit neuen Protokollen.
Die Debatte um KI-Klone verschiebt die Frage, was an freier Software schützenswert ist, vom Code zu den Tests. Freiheit des Quelltextes und Nachprüfbarkeit durch Dritte fallen damit ein Stück auseinander.

Zitate

„A v1.0 server will not open a store created by an earlier version.“ (Stalwart-Blog zu v1.0; sinngemäß: Ein Server der Version 1.0 öffnet keinen Speicher, der mit einer früheren Version angelegt wurde.)
„Email is forty years of accumulated edge cases, and you do not find them by reading the RFCs.“ (Stalwart-Blog „Private Tests, Public Code“; sinngemäß: E-Mail besteht aus vierzig Jahren angesammelter Randfälle, und die findet man nicht durch Lesen der RFCs.)

Fakten

Stalwart 1.0.0 erschien am 26. Oktober 2026, der erste Commit von mail-parser stammt vom 3. Oktober 2021.
stalwart-migrate setzt Version 0.16.27 voraus; ältere Installationen ziehen über Migrationsproxy und Vandelay um.
Im Vergleich mit Postfix 3.11.7 und Dovecot 2.4.5 lag Stalwart in 35 von 38 Hauptvergleichen vorn.
Volltextsuche über 250.000 Nachrichten: 3,75 ms bei Stalwart, 136 ms bei Dovecot.
Cluster benötigen ab 1.0 Redis, Redis Cluster oder Redis Sentinel als In-Memory-Speicher.

Referenzen

Kritik

Die SMTP-Zahlen (5.445 gegen 723 eingehende Nachrichten pro Sekunde) vergleichen nicht dieselbe Arbeit: Laut den eigenen Einschränkungen schreibt nur Postfix jede Nachricht vor der Bestätigung per fsync fest, und Stalwart ist für die Test-CPU übersetzt. Die Überschrift „schnellster Mailserver des Planeten“ beruht zudem auf einem Vergleich mit genau einem Gegner.
Mit den privaten Tests können Distributionen und Dritte ein Release nicht mehr mit der Testsuite des Projekts prüfen. Das Projekt räumt diese Kosten selbst ein; nachprüfbar bleibt damit vor allem das, was Stalwart misst und veröffentlicht.

Bemerkungen

Das Mailarchiv aus dem eigenen Beitrag „120.314 Mails aus 26 Jahren“ läuft auf Stalwart; für solche Installationen gilt der Migrationsweg oben.
heise online (iX) berichtete am 27. Oktober 2026; dieser Beitrag stützt sich auf Ankündigung, Changelog und Benchmark-Repository von Stalwart selbst.

Empfehlungen

Vor dem Umstieg erst auf 0.16.27 aktualisieren, dann stalwart-migrate in einen neuen, leeren Speicher laufen lassen und den alten Server bis nach dem Umschalten als Rückweg behalten.
Externen Identitätsanbieter vorab gegen das OAuth Profile for Open Public Clients prüfen, insbesondere die dynamische Client-Registrierung; sonst nach dem Upgrade mit Anmeldefehlern rechnen.
Für Cluster Redis oder Sentinel bereitstellen, bevor 1.0 eingespielt wird.
Die Benchmarks nicht übernehmen, sondern mit REPRODUCE.md aus dem Repository auf eigener Hardware und mit gleichem fsync-Verhalten nachstellen.

Originalbeitrag lesen

Im Webarchiv suchen