Stalwart 1.0 ist da – und das Update ist kein Update

Vor vier Tagen habe ich in „Stalwart 1.0 steht vor der Tür“ sortiert, was über die neue Version feststeht und was nicht. Am 26. Oktober 2026 ist Stalwart v1.0.0 erschienen. Zeit für einen Abgleich: Was ist drin, was hatte ich falsch eingeschätzt, und wie fühlt sich der Umstieg an?

Kurz gesagt: Funktional ein solides Release. Aber wer Stalwart 0.16 betreibt, kann nicht einfach das Image tauschen. 1.0 hat ein neues Datenbank-Layout, die Daten müssen mit einem eigenen Werkzeug umgezogen werden. Ich habe das mit einer Kopie meines Mailservers durchgespielt, ohne Probleme, aber mit einer Überraschung bei meinem eigenen Verwaltungstool.

Was neu ist

Die Release Notes sind lang. Für einen kleinen, selbst betriebenen Server sind diese Punkte die interessantesten:

• Volltextsuche in Anhängen: Stalwart indiziert jetzt auch den Text in PDF-, Word-, Excel-, PowerPoint-, OpenDocument-, EPUB- und RTF-Anhängen. Die Suche nach dem einen Angebot vom letzten Jahr findet dann auch das PDF.
• IMAP METADATA und JMAP-Metadaten: Programme können Zusatzinformationen an Postfächer, Mails, Kalender und Kontakte hängen.
• DKIM2 mit Post-Quanten-Signaturen: zusammengesetzte Signaturen aus ML-DSA-44 und Ed25519. Für den Alltag noch Zukunftsmusik, aber Stalwart ist hier wieder vorne dabei.
• OAuth aufgeräumt: Scopes pro Anwendung (mail, contacts, calendars, files) und eine Liste der verbundenen Programme, in der jeder Nutzer Zugriffe selbst widerrufen kann.
• Neues Cache-System mit eigener Stufe für große Konten.
• Vertrauenswürdige Proxys einstellbar: Wie viele Proxy-Stufen vor Stalwart sitzen und ob X-Forwarded-For oder Forwarded gilt, lässt sich jetzt festlegen. Wer Stalwart wie ich hinter einem Reverse Proxy betreibt, bekommt so verlässlich die echte Client-IP.
• SSRF-Schutz für ausgehende HTTP-Anfragen (Webhooks, OIDC, DNS-Anbieter).
• KI-Funktionen (Enterprise): ein KI-gestützter Spamfilter, der Modelle von OpenAI, Anthropic, Google oder ein lokales Ollama nutzen kann.

Eine eigene Webmail gibt es in 1.0 nicht. Das hatte das Team angekündigt, und so ist es auch gekommen.

Was ich falsch eingeschätzt hatte

In meinem Ausblick stand unter 🟡 „Angedeutet“: Das Update von 0.16 soll unspektakulär werden. Wahrscheinlich reiche es, das Image zu tauschen. Das Team hatte damals ausdrücklich geschrieben, das sei ein Ziel und keine Garantie.

Es ist anders gekommen. Die Release Notes beginnen mit diesem Satz:

This version includes multiple breaking changes and a new database layout, so existing v0.16.x deployments cannot be upgraded in place.

Konkret heißt das:

• 1.0 weigert sich, einen 0.16-Datenspeicher zu öffnen. Es bricht mit einer Fehlermeldung ab.
• Der Weg führt über das neue Werkzeug stalwart-migrate. Es liest den alten Speicher nur und schreibt in einen neuen, leeren Speicher für 1.0.
• Vorher muss der Server auf genau 0.16.27 stehen, der letzten 0.16-Version.
• Die Einstellungen werden umgewandelt. Einige Objekte und Felder heißen in 1.0 anders oder fallen weg.

Das klingt dramatischer, als es ist, denn das Werkzeug ist gut gemacht: Es fasst den alten Speicher nicht an, und der Weg zurück bleibt jederzeit offen. Wichtig ist aber eines:

⚠️ Wer stalwartlabs/stalwart:latest nutzt, sollte das sofort ändern. latest zeigt seit dem 26. Oktober auf 1.0. Beim nächsten docker compose pull oder automatischen Update (Watchtower!) startet 1.0 auf dem alten Speicher nicht, und der Mailserver steht. Im Installations-Tutorial steht deshalb bewusst v0.16. Dieses Tag zeigt auf genau die 0.16.27, die man für den Umstieg braucht.

Meine 🔴 Spekulation, dass schnell eine 1.0.1 folgt, ist noch offen. Ich würde weiter darauf wetten.

Mein Probelauf

Mein Mailserver läuft mit Stalwart 0.16.27 in Docker, mit dem eingebauten RocksDB als Speicher. Zehn Postfächer für Familie, Projekte und ein paar Absenderadressen für Formulare. Bevor ich daran irgendetwas ändere, wollte ich wissen, wie der Umstieg mit meinen Daten aussieht.

So habe ich es gemacht:

1. Als Kopie diente die nächtliche Sicherung. Für die wird Stalwart kurz angehalten, der Speicher ist also in sich stimmig.
2. Die Kopie kam auf einen anderen Server, in ein Docker-Netz ohne Internetzugang. So konnte die Testinstanz keine einzige Mail verschicken, keinen Bericht und kein Zertifikat abholen.
3. Dann lief das Werkzeug genau so, wie es die Migrationsanleitung beschreibt: erst prepare, dann run --final.

Das Ergebnis:

Danach habe ich Stalwart 1.0 auf der umgezogenen Kopie gestartet. Er lief sofort, alle Mail-Ports waren offen, und alle zehn Konten mit ihren Domains, Aliassen und der Liste gesperrter IP-Adressen waren da. Am Ende habe ich die Kopie mit allen Mails wieder gelöscht.

Die Fragen von prepare

prepare geht die Einstellungen durch und fragt bei Dingen nach, deren Verhalten sich ändert. Bei mir waren es vier:

• Welche Daten? Alles: Einstellungen, Konten, Mails, Kalender, Kontakte, Dateien, Sieve-Skripte, Spam-Training, Berichte, Warteschlange und so weiter. Die Warteschlange und geplante Aufgaben kopiert das Werkzeug erst im letzten Lauf, damit nichts doppelt zugestellt wird.
• Geänderte Standardwerte: Der Vorschlag „recommended“ behält die alten Werte dort, wo sich sonst das Verhalten ändern würde, etwa Pyzor im Spamfilter. Die übrigen übernimmt er von 1.0.
• OAuth-Clients: 1.0 nimmt keine unregistrierten Client-IDs mehr an. Wer mit OAuth arbeitet, muss sich nach dem Umstieg ohnehin neu anmelden.
• Neue Berechtigungen: Rollen bekommen die neuen Rechte, wenn sie vorher die passenden alten hatten.

Was entfällt, war bei mir harmlos: zwölf Spam-Tags für die KI-Klassifizierung, die ich nie genutzt habe, eine Thread-Pool-Einstellung und einige OAuth-Details.

Die Überraschung: mein eigenes Werkzeug

Für die Verwaltung im Alltag nutze ich nicht die Weboberfläche von Stalwart, sondern mailadmin, eine kleine App, die ich mir fürs Handy gebaut habe. Sie spricht mit der Verwaltungs-API von Stalwart.

Gegen 1.0 scheiterte sie beim Anlegen einer Domain mit Invalid key for object. Der Grund ist schnell gefunden: 1.0 hat die Ein/Aus-Schalter umbenannt.

Tückisch daran: Beim Lesen ignorieren beide Versionen ein unbekanntes Feld einfach. Die App zeigte also alles weiter brav als „aktiv“ an. Erst beim Schreiben lehnt der Server das Feld ab. Ohne gezielten Test wäre mir das erst nach dem Umstieg aufgefallen, beim ersten Versuch, einen Alias auszuschalten.

Die Lösung: mailadmin liest jetzt beide Namen, erkennt die Version an einer vorhandenen Domain und schreibt mit dem passenden Namen. Ein automatischer Test spielt Domain, Konto und Alias gegen beide Versionen durch und besteht mit 0.16.27 und mit 1.0.0. Damit kann ich die App schon vor dem Umstieg aktualisieren.

Aus eigener Erfahrung: Wer eigene Skripte oder Tools gegen die Verwaltungs-API von Stalwart betreibt, sollte sie vor dem Umstieg gegen eine 1.0-Testinstanz laufen lassen, und zwar mit Schreibzugriffen. Die meisten Objekte sind gleich geblieben, aber einzelne Felder nicht. Die vollständige Liste steht in SCHEMA_CHANGES.md im Repository des Werkzeugs.

Weitere Dinge, die man wissen sollte

• Mailprogramme laden nicht alles neu. IMAP-UIDs und die Änderungshistorie bleiben erhalten. Kalender- und Kontaktprogramme (CalDAV, CardDAV) holen ihre Daten einmal neu.
• Die Suche ist anfangs unvollständig. Der Volltextindex wird nach dem Start neu aufgebaut. Bei ein paar tausend Mails dauert das nicht lange.
• Die Weboberfläche unter /admin ist jetzt WebUI 2.x. Stalwart lädt sie selbst nach. Das Werkzeug stellt den Verweis darauf um, nur eigene Oberflächen muss man selbst anpassen.
• Der Weg zurück ist einfach, solange man den alten Speicher behält: Compose-Datei zurückstellen, alten Container starten. Mails, die in der Zwischenzeit nur in 1.0 angekommen sind, holt stalwart-migrate rollback in einen neuen 0.16-Speicher.

Und jetzt?

Mein Plan, und gleichzeitig meine Empfehlung:

1. Image-Tag prüfen. latest raus, v0.16 rein. Automatische Updates für Stalwart abschalten.
2. Auf 0.16.27 gehen, falls noch nicht geschehen.
3. Eigene Werkzeuge prüfen, die mit der Verwaltungs-API sprechen.
4. Probelauf mit einer Kopie. Das kostet eine halbe Stunde und nimmt dem eigentlichen Umstieg jeden Schrecken.
5. Nicht am ersten Tag umsteigen. Ich warte auf die erste Fehlerbehebungsversion oder ein, zwei Wochen Praxisberichte. Der eigentliche Wechsel dauert bei meinem kleinen Server dann etwa eine Viertelstunde Wartungsfenster.

Wie das im Detail geht, habe ich Schritt für Schritt aufgeschrieben: Tutorial: Stalwart von 0.16 auf 1.0 umziehen. Wenn ich meinen eigenen Server umgestellt habe, ergänze ich hier, wie es gelaufen ist.

Quellen:

• Stalwart v1.0.0 Release Notes
• Migration von 0.16 auf 1.0 (offizielle Dokumentation)
• stalwart-migrate auf GitHub
• Mein Ausblick: Stalwart 1.0 steht vor der Tür