Stalwart 1.0: kein In-Place-Upgrade, sondern Migration

Stalwart 1.0 ist seit dem 26. Oktober 2026 draußen, und wer 0.16.x betreibt, kann nicht einfach die neue Binärdatei starten. Der Hersteller hat das Datenbankschema neu gebaut. Dieser Beitrag ordnet ein, was im Release steht, was bei der Migration zu erwarten ist und was nur Herstellerangabe ist. Einen Nachtrag zu unserer eigenen Migration gibt es unten.

Stalwart 1.0 in 70 Wörtern: Stalwart 1.0 ist die erste stabile Version des quelloffenen Mail- und Kollaborationsservers von Stalwart Labs, der SMTP, IMAP, JMAP, CalDAV und WebDAV in einer Rust-Anwendung bündelt. Sie nutzt ein neues Datenbankschema, das 0.16-Bestände nicht öffnen können. Bestehende Installationen müssen deshalb mit dem Werkzeug stalwart-migrate in einen neuen, leeren Store kopiert werden, Ausgangsstand ist 0.16.27. Laut Hersteller soll künftig wieder ein normales Update genügen.

Kein In-Place-Upgrade von 0.16.x

Die Release Notes von 1.0.0 sagen es im ersten Absatz: Das Release bringt mehrere Breaking Changes und ein neues Datenbanklayout, bestehende 0.16.x-Installationen lassen sich nicht an Ort und Stelle aktualisieren. Der Release-Post ergänzt, ein v1.0-Server öffne keinen Store einer früheren Version. Der Hersteller begründet den Schnitt damit, dass das Schema jetzt stabil sei und künftige Versionen wieder per Update kommen sollen. Das ist eine Zusage des Herstellers, belegt ist sie erst mit den nächsten Releases.

Das README von stalwart-migrate beschreibt den Weg. Die neue Instanz startet mit leerem Speicher, das Werkzeug öffnet den alten Store schreibgeschützt und kopiert hinein, während 0.16 weiterläuft. Jeder weitere Durchlauf überträgt nur Änderungen, run --final schließt mit gestopptem 0.16 ab. Quelle muss 0.16.27 sein (veröffentlicht am 18. Oktober 2026), ältere 0.16-Stände müssen vorher darauf. Stand 5. November nennt das README außerdem, dass das Werkzeug Stores für Stalwart v1.0.3 und neuer schreibt.

Warum das Schema nicht an Ort und Stelle umzubauen war, zeigt die Schema-Doku des Werkzeugs. Alle numerischen Id-Räume wurden neu sortiert, nicht nur erweitert. Von den Namen, die in 0.16.27 und in 1.0.3 vorkommen, hat bei fast allen Server-Eigenschaften eine andere Id:

Wer in eigenen Skripten, Exporten oder im Monitoring mit rohen numerischen Ids der alten Instanz arbeitet, muss diese Stellen auf Namen umstellen. Wer mit Namen arbeitet, ist nach dem Umzug nicht betroffen.

Was das Release bringt

Der Release-Post nennt rund 200 Commits über mehr als 1.300 Dateien, die meisten für Geschwindigkeit. Parser für MIME-Grenzen, Header und Base64 nutzen jetzt SIMD- und SWAR-Kernel, die Bibliotheken mail-parser und encodify erscheinen gleichzeitig als 1.0. Die Messwerte dazu sind Herstellerangaben: mail-parser sei dreimal schneller als die Rust-Bibliothek mailparse, Base64-Dekodierung 22-mal schneller als die Standard-Crate auf einem AMD-EPYC-Server. Im Vergleich mit Postfix 3.11 und Dovecot 2.4 auf Azure-Servern mit 8 vCPU (EPYC Zen 5) und 32 GiB RAM sei Stalwart in 35 von 38 Hauptvergleichen schneller gewesen. Wir haben nichts davon nachgemessen.

Für den Betrieb zählen vor allem diese Änderungen aus dem Changelog:

• Neue Suchmaschine: Sie extrahiert Text aus PDF, Office-Dokumenten (docx, xlsx, pptx), OpenDocument, EPUB und RTF in Anhängen und im Dateispeicher. Der Suchindex wird nicht kopiert: v1 baut ihn nach dem Start neu auf, bis dahin sind Suchergebnisse unvollständig (README von stalwart-migrate).
• Migration als Kopie: Konto-, Dokument- und Thread-Ids sowie IMAP-UIDs behalten ihre Werte, IMAP-Clients laden ihre Postfächer deshalb nicht neu. OAuth-Tokens wandern nicht mit, CalDAV-, CardDAV- und WebDAV-Clients holen ihre Daten einmal neu, weil sich die Entity-Tags ändern.
• SSRF-Schutz für ausgehende HTTP-Anfragen: Der Changelog nennt Webhooks, OIDC-Discovery sowie KI- und DNS-Anbieter. Ein OIDC-Verzeichnis, das einen Identity Provider im privaten Netz erreichen soll, braucht ab 1.0.2 die Superuser-Einstellung trustedProvider.
• Strengere OAuth-Regeln: Das OAuth-Profil für öffentliche Clients wird vollständig durchgesetzt; wer einen externen OIDC-Provider nutzt, muss laut Changelog dessen Fähigkeiten prüfen. Seit 1.0.3 brauchen Apps von Drittanbietern zusätzlich die neuen Stalwart-Scopes.
• Post-Quantum-DKIM2: 1.0.0 führte eine zusammengesetzte Signatur aus ML-DSA-44 und Ed25519 ein. 1.0.2 ersetzt sie nach dem Entwurf draft-ietf-dkim-dkim2-spec-08 durch reines ML-DSA-44. Das ist ein Entwurf, kein verabschiedeter Standard.

Der Changelog von 1.0.0 nennt außerdem „multiple bug and security fixes“, ohne einzelne Schwachstellen aufzuführen. Ein Notfall-Update ist daraus nicht abzulesen, die Migration ist aber Pflicht, sobald man auf 1.0 will.

Die privaten Tests

Am 16. Oktober 2026 kündigte Stalwart im Beitrag „Private Tests, Public Code“ an, die Testsuite samt Fixtures in ein privates Repository zu verlegen. Neue Funktionen sollen privat entwickelt und als fertiger Commit unter der AGPL veröffentlicht werden. Begründung des Herstellers: Eine Testsuite sei für KI-Agenten ein Orakel, mit dem sich Nachbauten unter anderer Lizenz erzeugen ließen. Der Hersteller stellt klar, dass die AGPL die Tests nicht als Quellcode verlangt, und will die Entscheidung jährlich prüfen und die Tests zurückbringen, sobald es rechtlichen Schutz gegen solche Nachbauten gibt.

Für den Betrieb heißt das: Der öffentliche Code lässt sich weiter lesen und bauen, ob er getestet ist, kann man von außen nicht mehr nachvollziehen. Eine unabhängige Diskussion dazu haben wir nicht gefunden. Die bei Hacker News eingestellte Meldung zum Beitrag hatte bei unserer Prüfung am 5. November 4 Punkte und keinen Kommentar. Ob einem das reicht, muss jeder Betreiber für sein System entscheiden.

Messbasis dieses Beitrags

Die ersten beiden Zeilen sind unsere Messungen, die übrigen Herstellerangaben. Beides steht bewusst getrennt.

Was sich an der Lizenz ändert

An den Lizenzen ändert sich laut Quelle nichts Neues. Das README nennt eine Doppellizenz aus AGPL-3.0 und Stalwart Enterprise License v2 (SELv2), die Texte liegen im Ordner LICENSES (AGPL-3.0-only.txt, Apache-2.0.txt, LicenseRef-SEL.txt); eine Datei LICENSE im Wurzelverzeichnis gibt es nicht. Nach dem README stecken etwa 85 Prozent der Funktionen in der AGPL-Fassung, der Rest ist Enterprise-Edition. Laut Schema-Doku gehört dazu etwa die Berechtigung interactAi. Wer den Code ändert und über das Netz anbietet, bleibt im AGPL-Pflichtenkreis.

Migration in der richtigen Reihenfolge

1. Quelle auf 0.16.27 bringen. Das Werkzeug verlangt diesen Stand.
2. Bestand sichern und alle Stellen finden, die mit rohen Ids statt Namen arbeiten.
3. Mit prepare die Einstellungsumsetzung prüfen und die offenen Entscheidungen festhalten.
4. run auf einem Testbestand fahren und report lesen: Dort stehen verworfene, geänderte und gekürzte Objekte.
5. Eine Rückfalllinie einplanen. Die alte Instanz wird nie beschrieben und kann bis zum Umschalten weiterlaufen, das Werkzeug kennt außerdem rollback.
6. Nach dem Umschalten die Anmeldung testen, besonders OAuth-Clients und Webmail, danach DAV-Clients und die Suche, bis der Index neu aufgebaut ist.

Ein Umzug, der die Mailboxen migriert und die Anmeldung still abbrechen lässt, ist kein gelungener Umzug. Deshalb gehört der Test mit einem echten Konto vor das Stilllegen der alten Instanz.

Nachtrag vom 5. November 2026

Ursprünglich stand hier eine Balkengrafik mit Prozentwerten, deren Nenner nicht zur Tabelle des Herstellers passten, dazu ein Verweis auf eine Hacker-News-Diskussion, der auf einen anderen Thread zeigte, und Angaben zu Typänderungen, die in der Quelle so nicht stehen. Diese Stellen haben wir gegen die Quellen korrigiert, deshalb das neue Änderungsdatum. Unsere eigene Migration auf 1.0.2 haben wir am 2. November gemacht, die Zahlen und Stolpersteine stehen im Beitrag Stalwart 1.0 migrieren: Schritt für Schritt mit allen Stolpersteinen. Den Vergleich mit anderen Mailsystemen liefert Stalwart, Axigen und Exchange im Betrieb. Mehr zum Betrieb von Servern und Netzwerk sammelt das Thema Server, Proxmox und Netzwerk. Wer einen Mailserver-Umzug nicht allein planen will, findet unsere Angebote auf der Leistungsübersicht.

Weiterführende Quellen

• Stalwart v1.0.0, Release Notes (26. Oktober 2026, Herstellerangabe)
• Stalwart v1.0: The Fastest Mail Server on the Planet (Release-Post, 26. Oktober 2026, Herstellerangabe)
• Private Tests, Public Code (Hersteller-Blog, 16. Oktober 2026)
• stalwart-migrate, README und SCHEMA_CHANGES.md
• Stalwart CHANGELOG.md und README mit Lizenzabschnitt
• draft-ietf-dkim-dkim2-spec-08 (IETF-Entwurf)