Open Archiver Updates: Sicherheitslücken und kritische Fixes (Stand: v0.6.2)

Ich betreibe Open Archiver selbst, um meine E-Mails auf dem eigenen Server zu archivieren, und verfolge jedes Release. In diesem Beitrag sammle ich alle Updates, bei denen Du handeln solltest: Sicherheitslücken, Fehler mit Datenverlust und Stolperfallen beim Update. Die neueste Version steht immer oben.

Aktuell ist Version 0.6.2 vom 24. Oktober 2026. Sie schließt eine kritische Sicherheitslücke, die sich ohne Anmeldung ausnutzen lässt. Dieses Update solltest Du sofort einspielen.

Aktueller Stand: Version 0.6.2 – das musst Du tun

Achtung, falls Du einer früheren Fassung dieses Beitrags gefolgt bist: Dort hatte ich empfohlen, das Image fest auf logiclabshq/open-archiver:v0.5.2 zu setzen. Dann kommt der Fix nicht von allein, auch nicht mit einem Neu-Deploy. Trag v0.6.2 ein.

Ob das Update gegriffen hat, prüfst Du mit docker exec open-archiver node --version. Die Ausgabe muss v22.23.4 oder neuer lauten. In Portainer geht das auch über die Konsole des Containers open-archiver mit node --version.

Version 0.6.2 (24.10.2026): Sicherheitslücke in Node.js

Am 21. Oktober 2026 hat das Node.js-Projekt eine Lücke im mitgelieferten Brotli-Decoder geschlossen (CVE-2026-111497). Präparierte, komprimierte Daten können dort über einen internen Puffer hinausschreiben. Die Folgen reichen vom Absturz über ausgelesenen Speicher bis zur Ausführung von Schadcode. Open Archiver nutzt diesen Decoder an zwei Stellen:

• Eingehende Anfragen: Jeder Endpunkt entpackt Brotli-komprimierte Anfragen, auch der Login. Ein Angreifer braucht also nur Zugriff auf den Web-Port, kein Konto.
• Ausgehende Anfragen: Abrufe bei Microsoft 365, Google Workspace und JMAP-Servern, die Textextraktion über Tika und der Update-Check bei GitHub.

Version 0.6.2 ändert keinen Programmcode, sondern baut das Image auf einem gepatchten Node.js neu. PostgreSQL, Valkey, Meilisearch und Tika sind laut den Release Notes zu 0.6.2 nicht betroffen. Läuft vor Open Archiver ein Reverse Proxy, prüfst Du den separat beim jeweiligen Hersteller.

So updatest Du auf 0.6.2: 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 in 0.5.1. 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 oder neuer. Dann bleibt Meilisearch, wie es ist.

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 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 und Valkey sind bis 0.6.2 unverändert, Tika kannst Du optional anheben (siehe unten). Die env.example hat seit 0.6.0 zwar neue Einträge, für die bringt Open Archiver aber Standardwerte mit. Deine bestehende .env kannst Du weiterverwenden.

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.6.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 oder neuer

Deutlich entspannter. Meilisearch, PostgreSQL und Valkey bleiben unverändert, Du musst also kein Volume anfassen. Neu ist seit 0.6.1 nur die Tika-Version, und auch die ist optional.

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.6.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 der alten Version, ohne dass es jemand merkt. An Meilisearch änderst Du nichts.
3. Tika optional anheben, siehe nächster Abschnitt.
4. Vollständigen Reindex anstoßen, wenn Du von 0.5.1 kommst. Ab 0.5.2 ist er nicht nötig.

Tika 3 oder 4?

Seit 0.6.1 steckt apache/tika:4.1.0-full in der offiziellen Compose-Datei. Zwingend ist der Wechsel nicht: Open Archiver erkennt Tika 3 und 4 selbst. Tika speichert keine Daten, Du kannst also gefahrlos wechseln und notfalls zurück. Ändere die Tika-Zeile aber nur zusammen mit dem Open-Archiver-Image, denn ältere Versionen kennen Tika 4 nicht. Auf 32-Bit-ARM bleibst Du bei 3.2.2.0-full, dafür gibt es kein Tika-4-Image mehr.

Der Reindex

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.

Fehler „Cannot reach the Open Archiver API“: Ursachen und Lösung

Statt der Anmeldeseite zeigt Open Archiver nur: Cannot reach the Open Archiver API. Please try again in a moment. Diese Meldung gibt es seit Version 0.6.0. Sie bedeutet: Die Weboberfläche läuft, aber das Backend dahinter antwortet nicht. Beide stecken im selben Container open-archiver. Ältere Versionen zeigten in derselben Lage einfach die Anmeldeseite, und der Login scheiterte mit „fetch failed“.

Zuerst kurz warten. Direkt nach dem Start ist die Weboberfläche oft schneller bereit als das Backend. Lade die Seite nach ein bis zwei Minuten neu.

Bleibt die Meldung, schau ins Log – in Portainer unter Containers > open-archiver > Logs oder mit docker logs open-archiver --tail 100. Steht dort Failed to start the server, ist das Backend beim Start abgebrochen. Wichtig: Es startet danach nicht von selbst neu. Weil die Weboberfläche weiterläuft, zeigt Portainer den Container trotzdem als „running“ an. Nach jeder Korrektur musst Du den Container open-archiver deshalb selbst neu starten.

Ursache 1: Meilisearch läuft nicht

Das Backend verbindet sich beim Start mit Meilisearch und richtet den Suchindex ein. Ist Meilisearch nicht erreichbar, bricht der Start ab. Der typische Auslöser ist der Versionssprung aus Weg A: Wer von 0.5.0 oder älter kommt und nur das Image auf v1.38 umstellt, behält die alte Indexdatenbank, und der neue Meilisearch-Container startet damit nicht. Genau dieses Muster beschreibt Issue #446: Anmelden war unmöglich, bis Meilisearch wieder lief.

So prüfst Du es: Steht der Container meilisearch in Portainer auf „exited“ oder startet er ständig neu, nennt sein Log den Grund. Die Lösung ist Weg A: nur das Meilisearch-Datenverzeichnis leeren, Stack neu starten, Suchindex neu aufbauen. Danach open-archiver neu starten.

Ursache 2: Leere oder doppelte Werte in der .env

Ohne JWT_SECRET und JWT_EXPIRES_IN startet das Backend nicht. Im Log steht dann entweder genau das oder, wie mehrere Nutzer in Issue #252 berichten, nur ein nichtssagendes Failed to start the server mit error: {}. Prüfe Deine stack.env: Sind alle Schlüssel gesetzt, und kommt keine Variable doppelt vor, einmal mit und einmal ohne Wert? Ein zweiter, leerer ENCRYPTION_KEY war bei einem Nutzer in Issue #230 genau die Ursache.

Ursache 3: Valkey verweigert die Anmeldung (WRONGPASS)

Ältere Fassungen der env.example enthielten die Zeile REDIS_USER=notdefaultuser. Der mitgelieferte Valkey-Server kennt diesen Benutzer nicht und lehnt jede Verbindung ab. Seit 0.6.0 ist die Zeile in der Vorlage auskommentiert, eine bestehende .env ändert ein Update aber nicht. Das trifft vor allem Neuinstallationen. Taucht im Log WRONGPASS auf, setzt Du ein # vor die Zeile und startest den Stack neu.

Seite lädt gar nicht? Dann ist es etwas anderes

Erscheint überhaupt keine Seite, läuft der Container open-archiver gar nicht. Er führt vor dem Start die Datenbank-Migrationen aus und beendet sich, wenn er PostgreSQL nicht erreicht. Häufig steht dann password authentication failed for user im Log. PostgreSQL übernimmt das Passwort aus der .env nur beim allerersten Start mit leerem Datenverzeichnis. Hast Du es danach geändert, passt es nicht mehr, und ein erneutes Deployen hilft nicht. Abhilfe aus Issue #253: das Passwort direkt in der Datenbank angleichen.

docker exec -it postgres psql -U admin -d open_archive
ALTER USER admin WITH PASSWORD 'DeinPasswortAusDerEnv';

Was 0.6.0 und 0.6.1 sonst noch ändern

Wer von 0.5.x kommt, überspringt zwei größere Versionen. Das sind die Punkte, die Du kennen solltest.

Version 0.6.0 (24.08.2026) brachte selbst wichtige Sicherheitsfixes:

• Rechte werden pro Datensatz geprüft. Vorher prüfte Open Archiver nur, ob eine Rolle auf eine Art von Ressource zugreifen darf. Eine Rolle, die auf eine Erfassungsquelle beschränkt war, kam so auch an andere heran.
• Keine Passwort-Hashes mehr in der Benutzerliste. Die API lieferte Passwort-Hash, verschlüsseltes 2FA-Geheimnis und Backup-Codes an jede Rolle mit Leserecht auf Benutzer aus, auch an die mitgelieferte Read-only-Rolle.
• Zwei-Faktor-Anmeldung (TOTP) ist jetzt auch in der Open-Source-Version enthalten.
• OAuth-Postfach für Outlook.com, Hotmail und Live.com, die sich per IMAP nicht mehr einbinden lassen.
• Entwürfe werden nicht mehr archiviert. Wer sie weiter im Archiv haben will, setzt ARCHIVE_DRAFTS=true.
• Keine doppelten Mails mehr durch überlappende Sync-Läufe. Bereits vorhandene Duplikate bleiben aber bewusst liegen.
• ADMIN_EMAIL und ADMIN_PASSWORD in der .env werden ignoriert und können raus.

Version 0.6.1 (20.10.2026):

• JMAP als neue Quelle, etwa für Fastmail oder Stalwart.
• Platzhalter in der Suche: *@example.com findet alle Adressen einer Domain. Für ältere Mails greift das erst nach einem vollständigen Neuaufbau des Index.
• Fehlende Mails in der Suche aufspüren: Manche Mails sind als indexiert markiert, fehlen aber im Suchindex – laut Release Notes meist Überbleibsel des Updates auf 0.5.1. Die neue Aktion „Verify index coverage“ im Admin-Bereich auf der Index-Seite findet sie und indexiert sie nach, ohne etwas zu löschen. Wer den Meilisearch-Sprung hinter sich hat, sollte sie einmal laufen lassen.
• Tika 4 ist der neue Standard in der Compose-Datei.
• Das Datumsformat stellst Du jetzt zentral in den Systemeinstellungen ein.

Version 0.5.2 (27.07.2026): Importe verschluckten Mails

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.

Fazit

Open Archiver entwickelt sich schnell, und fast jedes Release behebt etwas, das Du bei einem Archiv nicht aufschieben solltest: erst verschluckte Mails, dann zu weit reichende Rechte, jetzt eine Lücke, die ohne Anmeldung ausnutzbar ist. Setz das Image auf eine feste Version, wirf bei jedem Release einen Blick hierher oder in die Release Notes und halte ein aktuelles Backup bereit. Ich ergänze diesen Beitrag, sobald die nächste wichtige Version erscheint.

Links:

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