In Open Archiver 0.5.2 wurde ein kritischer Fehler gefixt: frühere Versionen verschluckten Mails

Ich habe Open Archiver vor Kurzem als interessante Lösung vorgestellt, um E-Mails auf dem eigenen Server zu archivieren. Bis einschließlich Version 0.5.1 konnten unter bestimmten Umständen Importe erfolgreich aussehen, obwohl im Archiv Mails fehlten, beschädigt ankamen oder doppelt gespeichert wurden.

Für eine Archivierungssoftware ist das kein kleiner Schönheitsfehler, sondern der denkbar schlimmste Bug. Mit Version 0.5.2 wurden jetzt genau diese Fehler behoben.

Das Problem: Der Import war fertig, aber Mails fehlten

In den Release Notes zu Version 0.5.2 schreiben die Entwickler ungewöhnlich offen, dass mehrere Fehlerpfade geschlossen wurden, auf denen ein Import Nachrichten überspringen oder duplizieren und trotzdem Erfolg melden konnte.

Wichtig zur Einordnung: Die nun dokumentierten Datenverluste betrafen vor allem dateibasierte Importe wie mbox und PST sowie problematische Datei- und Anhangsnamen. Das bedeutet nicht automatisch, dass jede frühere IMAP-, Google- oder Microsoft-365-Synchronisation unvollständig war. Wer mbox- oder PST-Dateien importiert hat, sollte seinen Bestand aber unbedingt kontrollieren.

So konnten Mails im Archiv verloren gehen

mbox: Aus mehreren Mails wurde eine

Eine mbox-Datei enthält viele E-Mails hintereinander. Ein sogenannter Splitter muss diesen Datenstrom deshalb in einzelne Nachrichten zerlegen.

Genau hier lag ein schwerer Fehler: Der Splitter arbeitete auf seiner Ausgabeseite als normaler Byte-Stream statt im Object Mode. Node.js fügte dadurch mehrere bereits getrennte Nachrichten-Buffer wieder zusammen. Beim nächsten Verarbeitungsschritt kamen mehrere Mails als ein einziger Block an – und wurden entsprechend als eine einzige Nachricht archiviert.

Der Import konnte trotzdem als erfolgreich erscheinen. Gleichzeitig fehlte eine ausgegebene Nachrichtenzahl, mit der sich Quelle und Archiv einfach hätten vergleichen lassen.

In 0.5.2 bleiben die Nachrichten nun getrennt. Zusätzlich protokolliert der mbox-Parser die Anzahl der erkannten Mails. Damit lässt sich zumindest sofort sehen, wenn die Zahlen nicht zusammenpassen.

PST: Kaputte MIME-Struktur und doppelte Importe

Auch der Import von Outlook-PST-Dateien hatte gleich mehrere Probleme. Open Archiver erzeugte daraus teilweise formal ungültige MIME-Nachrichten: doppelte Content-Type-Header, ein Body-Teil ohne Header und rohe Binärdaten an der falschen Stelle.

Die Folgen waren unterschiedlich:

• HTML-Inhalte erschienen als Quelltext
• Empfänger konnten fehlen
• Inline-Bilder mit cid:-Verweisen wurden nicht angezeigt
• Anhänge und Nachrichtenteile ließen sich nicht sauber zuordnen

Die E-Mail war dann zwar grundsätzlich im Archiv, aber unter Umständen unvollständig oder kaum lesbar. Für eine spätere Recherche oder einen rechtlichen Nachweis ist das fast so problematisch wie eine komplett fehlende Nachricht.

Dazu kam ein zweiter PST-Bug: Die intern gebildete Postfach-ID blieb zwischen zwei Importläufen nicht stabil. Bei einem erneuten Abgleich konnte deshalb die gesamte PST-Datei noch einmal als Sammlung neuer Nachrichten importiert werden. Das Archiv hatte also im schlimmsten Fall gleichzeitig Lücken und Duplikate.

Version 0.5.2 baut PST-Nachrichten nun nach RFC 5322 und RFC 2046 auf, einschließlich sauberem Multipart-Aufbau, CRLF-Zeilenenden, base64-kodierten Inhalten und korrekten Content-IDs für Inline-Anhänge. Auch die Postfach-Identität bleibt über mehrere Läufe hinweg stabil.

Ein zu langer Anhangsname konnte die ganze Mail stoppen

Besonders tückisch war der Umgang mit Dateinamen. Open Archiver übernahm Anhangsnamen aus MIME-Headern direkt in den Speicherpfad. War ein Name länger als das bei vielen Dateisystemen übliche Limit von 255 Byte, schlug der Schreibvorgang fehl.

Verloren ging dabei nicht nur der Anhang, sondern unter Umständen die gesamte E-Mail. Auch Schrägstriche oder .. im Dateinamen konnten unbeabsichtigte Unterverzeichnisse erzeugen.

Open Archiver bereinigt und kürzt solche Pfadbestandteile jetzt bytegenau. Ein kurzer Hash am Ende verhindert Namenskollisionen. Der ursprüngliche Dateiname bleibt unverändert in der Datenbank erhalten.

Große PST-Importe konnten den Speicher füllen

Lokale PST-Dateien wurden vor dem Einlesen in ein temporäres Verzeichnis kopiert. Bei einer 40 GB großen PST-Datei bedeutete das noch einmal 40 GB zusätzlichen Platzbedarf. War die Platte voll, brach der Import ab und das Archiv blieb unvollständig.

Die neue Version liest lokale PST-Dateien direkt am ursprünglichen Speicherort. Verwaiste temporäre Verzeichnisse werden anhand der zugehörigen Prozess-ID aufgeräumt. Nicht lesbare Dateien lassen außerdem nur noch den jeweiligen Job kontrolliert fehlschlagen, statt den ganzen Worker mitzureißen.

Warum der Fehler schlimmer war, als ein Versagen

Ein Import, der mit einer klaren Fehlermeldung abbricht, ist ärgerlich, aber sichtbar. Du behebst die Ursache und startest ihn erneut.

Viel gefährlicher ist ein Import, der „erfolgreich“ meldet und dabei Mails übersieht. Er erzeugt ein Archiv, dem Du vertraust, obwohl es unvollständig ist. Bemerken wirst Du das möglicherweise erst Jahre später – wenn Du genau die Nachricht suchst, die nicht archiviert wurde, und das ursprüngliche Postfach längst nicht mehr existiert.

Bei geschäftlichen E-Mails kommt die Aufbewahrungspflicht hinzu. Empfangene und abgesandte Handelsbriefe sind in Deutschland nach § 257 HGB grundsätzlich sechs Jahre, Buchungsbelege acht Jahre aufzubewahren. Die GoBD verlangen unter anderem Vollständigkeit und Nachvollziehbarkeit. Enthält ein Archiv Lücken bei aufbewahrungspflichtigen Nachrichten, kann es diese Anforderungen nicht erfüllen. Die konkrete rechtliche und steuerliche Bewertung gehört natürlich zum Steuerberater.

Fairerweise muss man sagen: Das Open-Archiver-Team verschweigt die Probleme nicht. Die technischen Ursachen stehen detailliert in den Release Notes. Die Dokumentation macht zugleich klar, dass ein Reindex nur den Suchindex aus bereits archivierten Daten neu aufbaut und verlorene Nachrichten nicht zurückholen kann. Diese Transparenz ist bei einem jungen Open-Source-Projekt ein gutes Zeichen.

Version 0.5.2 verbessert auch die Suche

Die Fehlerbehebungen sind für mich die wichtigste Neuerung. Sichtbarer ist aber die neue erweiterte Suche.

Ergebnisse lassen sich jetzt filtern nach:

• Importquelle
• Absender und Empfänger
• einzelnem Postfach
• Zeitraum
• Mails mit oder ohne Anhang

Absender, Empfänger und Quellen können sowohl ein- als auch ausgeschlossen werden. Außerdem lässt sich der Suchbegriff gezielt auf Betreff, Nachrichtentext, Anhangsname, Anhangsinhalt, Absender oder Empfänger begrenzen.

Eine Suche nach Rechnung im Anhangsnamen findet damit beispielsweise eine Datei namens rechnung_2026.pdf, ohne gleichzeitig jede Mail aufzulisten, in deren Text das Wort vorkommt. Der komplette Suchzustand steckt in der URL und kann deshalb als Lesezeichen gespeichert oder geteilt werden. Dieselben Filter stehen über GET /v1/search auch in der API zur Verfügung.

Vollständiger Reindex wichtig!

Für bestehende Archive ist der vollständige Reindex wichtig: Der Anhangsfilter nutzt das neue Feld hasAttachments, aufgelöste Absendernamen das Feld fromName. Ohne Neuaufbau gelten alte Mails beim Filtern zunächst als anhangslos und zeigen in Suchergebnissen gegebenenfalls nur die Absenderadresse.

So updatest Du: zwei Wege, je nach Ausgangsversion

Beim Update gibt es einen Punkt, der leicht übersehen wird: Ein Blick in die offiziellen Compose-Dateien zeigt, dass zwischendurch die Meilisearch-Version gewechselt hat.

Der Sprung steckt also bereits in 0.5.1, nicht in 0.5.2. Daraus ergeben sich zwei ganz unterschiedliche Update-Wege – such Dir den passenden heraus:

• Weg A: Du kommst von 0.5.0 oder älter. Dann musst Du den Suchindex komplett neu aufbauen.
• Weg B: Du kommst von 0.5.1. Dann bleibt Meilisearch, wie es ist – ein Reindex ist trotzdem fällig.

Wer nach meiner Installationsanleitung eingerichtet hat, ist in der Regel auf Weg A. Ich selbst übrigens auch.

Weg A: Update von 0.5.0 oder älter

Hier gilt: Die Datenbank von Meilisearch v1.15 ist mit v1.38 nicht kompatibel. Ein bloßer Austausch des Container-Images reicht nicht. Solange die alte Indexdatenbank im Datenverzeichnis liegt, verweigert der neue Meilisearch-Container den Start. Und weil Open Archiver von diesem Dienst abhängt, startet anschließend auch Open Archiver nicht.

Ich halte ich den kompletten Neuaufbau für die bessere Wahl. Meilisearch enthält bei Open Archiver ausschließlich den Suchindex – die eigentlichen E-Mails liegen als .eml im Dateisystem oder auf S3, die Metadaten in PostgreSQL. Der Index ist also abgeleitete Daten und jederzeit reproduzierbar. Dazu kommt: 0.5.2 braucht für die neuen Suchfelder hasAttachments und fromName sowieso einen vollständigen Reindex. Du würdest den Aufbau also ohnehin einmal komplett durchlaufen lassen.

Dabei darfst Du ausschließlich das Meilisearch-Datenverzeichnis leeren – niemals das PostgreSQL-Volume oder das Verzeichnis mit den archivierten E-Mails.

So gehst Du vor:

Du lädst dafür keine neue Compose-Datei herunter. Es genügt, Deinen bestehenden Stack an zwei Stellen anzufassen – alles andere bleibt, wie es ist. PostgreSQL, Valkey und Tika sind zwischen 0.5.0 und 0.5.2 unverändert, und auch in der env.example ist keine einzige Variable dazugekommen.

1. Backup prüfen. Bevor Du an Datenverzeichnisse gehst, muss ein aktuelles vollständiges Backup vorhanden sein: Maildateien, PostgreSQL, Konfiguration und Schlüssel.

2. Meilisearch-Zeile im Stack ändern. Öffne Deinen Stack im Portainer-Editor und setze das Meilisearch-Image von v1.15 auf v1.38:

   meilisearch:
     image: getmeili/meilisearch:v1.38

3. Open-Archiver-Image auf die exakte Version setzen. Im offiziellen Compose steht logiclabshq/open-archiver:latest. Genau das würde ich in Portainer nicht so stehen lassen: Beim Neu-Deployen zieht Portainer nicht zwingend ein frisches Image, sondern nimmt oft das bereits lokal vorhandene. Du startest den Stack dann erfolgreich neu – und läufst trotzdem weiter auf der alten Version, ohne dass Dir irgendetwas auffällt. Trag deshalb den konkreten Tag ein:

   open-archiver:
     image: logiclabshq/open-archiver:v0.5.2

   Damit ist eindeutig, was läuft, und Du siehst später auf einen Blick, auf welchem Stand Deine Installation ist. (Der Vollständigkeit halber: Wer bei latest bleiben will, muss beim Deploy zwingend die Option „Re-pull image“ aktivieren.)

4. Stack stoppen. Fahre Open Archiver mit docker compose down oder über Portainer herunter.

5. Meilisearch-Speicher eindeutig identifizieren. Bei einem Bind-Mount – also dem Setup aus meiner Anleitung – ist das Dein Host-Ordner, der im Container auf /meili_data zeigt. Nutzt Du dagegen die Named Volumes aus dem offiziellen Compose, heißt das Volume meilidata. Kontrolliere die Zuordnung vorher in Portainer oder mit docker volume inspect. Und ja: einmal zu viel hinschauen ist hier besser als einmal zu wenig.

6. Nur den alten Meilisearch-Index entfernen. Leere den identifizierten Ordner beziehungsweise entferne ausschließlich das geprüfte Meilisearch-Volume.

7. Stack neu starten. Starte die Container neu, in Portainer über „Update the stack“. Meilisearch legt nun eine frische, leere Datenbank an.

8. Vollständigen Reindex anstoßen. Wie das geht, steht gleich unten – für Weg A und Weg B identisch.

Weg B: Update von 0.5.1

Deutlich entspannter. Zwischen 0.5.1 und 0.5.2 ändert sich am Compose-Stack nichts – gleiche Meilisearch-Version, gleiche PostgreSQL-, Valkey- und Tika-Images, keine neuen Variablen in der env.example. Du musst also weder ein Volume anfassen noch eine Zeile in der Compose-Datei ändern.

1. Backup erstellen. Auch wenn hier nichts gelöscht wird: Vor einem Update gehört ein Backup dazu.
2. Open-Archiver-Image auf logiclabshq/open-archiver:v0.5.2 setzen und den Stack neu deployen. Auch hier gilt: Lieber den exakten Tag eintragen als auf latest zu vertrauen – sonst startet der Stack sauber durch und läuft weiterhin auf 0.5.1, ohne dass es jemand merkt. An Meilisearch änderst Du nichts.
3. Vollständigen Reindex anstoßen. Der ist trotzdem nötig – dazu jetzt.

Der Reindex: für beide Wege gleich

Ohne Reindex bleiben die neuen Suchfelder für Deinen Bestand leer. Alte Mails gelten dann beim Anhangsfilter als anhangslos und zeigen in den Ergebnissen unter Umständen nur die Absenderadresse statt des Namens.

Und so stößt Du ihn an:

1. Öffne im Menü Archiv den Punkt Erfassungen.
2. Klicke rechts oben auf den Button Reindex All.
3. Wähle Rebuild all und nicht den Modus „Missing“. „Missing“ ergänzt nur Dokumente, die im Index fehlen – nach einem geleerten Index brauchst Du aber den kompletten Neuaufbau, und auch für die neuen Suchfelder reicht „Missing“ nicht.

Den Fortschritt inklusive Task-Liste und Fehlermeldungen kannst Du als Super Admin im Admin-Bereich auf der Index-Seite verfolgen.

Der Neuaufbau ist idempotent: Bereits vorhandene Mails werden im Suchindex aktualisiert und nicht als doppelte Archivdaten angelegt. Je nach Größe des Archivs und Anzahl der Anhänge kann der Vorgang allerdings längere Zeit dauern.

Wichtig bleibt der Unterschied: Der Reindex repariert den Suchindex. Mails, die eine ältere Open-Archiver-Version beim Import nie in PostgreSQL und im Dateispeicher abgelegt hat, kommen dadurch nicht zurück. Sie müssen erneut aus der ursprünglichen Quelle importiert werden.

Fazit

Wenn Du eien ältere Version hast, musst Du unbedingt updaten! Sonst kann es passieren, dass archiviert geglaubte E-Mails nicht archiviert wurden.

Links:

• Open Archiver installieren – Anleitung auf deutsch
• E-Mails archivieren: Mail Archiver vs. Open Archiver
• Open Archiver 0.5.2 – Release Notes
• Dokumentation zu Suche und Reindex
• Dokumentation zum Meilisearch-Upgrade