Archivierung und Journaling

Das Archiv ist ab 0.1.0 enthalten. In 0.4.7 füllen fünf Wege es: der Empfang von Exchange-Online-Journalberichten per SMTP, die Graph-Erfassung von Microsoft-365-Postfächern, von einem Mailanbieter weitergeleitete Kopien, die IMAP-Archivierung von IMAP- und Google-Workspace-Konten (die ersten vier brauchen eine Lizenz Business oder Service Provider, die letzten drei seit 0.4.4) und der Mail-Import mit der Option, gleichzeitig zu archivieren (jede Edition, auch Community). Es ist ein nur anhängbarer Speicher mit SHA-256-Hash-Kette und einer Archivprüfung (jedes Glied, die jede Nacht versiegelten Tagesanker und auf Wunsch eine Stichprobe der gespeicherten Nachrichten), durchsuchbar nach Betreff, Adressen und (bei importierter Mail) Nachrichtentext, mit einer festen Aufbewahrung von 8 Jahren, Export als EML oder MBOX und einem Nachweisbericht als JSON über die Integrations-API, in jeder Edition. Durchgesetzte Aufbewahrung und Legal Hold brauchen Business oder Service Provider. Geplant (ohne Termin; die Roadmap ordnet es): externe Tagesanker, Object Lock, das der eigenen Aufbewahrung des Archivs folgt, eine Aufbewahrungsrichtlinie je Mandant, Suche in Anhängen, Self-Service- und rollenbezogene Suche, ein Prüfer-Export, ein signierter PDF-Nachweisbericht, eine Wahl je Postfach und ein Generator für die Verfahrensdokumentation. Siehe Archivierung für die genaue Statusliste und Backup vs. Archiv dafür, warum Backup und Archiv bewusst getrennte Systeme sind.

Erfassungswege

Fünf Wege füllen das Archiv.

Weg	Mailquelle	Erfassung	Stand
Exchange-Online-Journaling	Microsoft 365	Echt: beim Transport, vor der Zustellung	Verfügbar seit 0.1.0 (Business, Service Provider)
Graph-Erfassung	Microsoft 365	Zeitnah: aus dem Postfach, kurz nach der Zustellung	Verfügbar seit 0.4.4 (Business, Service Provider)
Weiterleitung an die Journal-Adresse	IMAP-Anbieter mit serverseitiger Kopie (BCC- oder Weiterleitungsregel), Google Workspace (Routing-Regel)	Echt: im Transport des Anbieters	Verfügbar seit 0.4.4 (Business, Service Provider)
IMAP-Archivierung	Jedes IMAP-Konto, auch Google Workspace	Zeitnah: aus dem Postfach, laufend	Verfügbar seit 0.4.4 (Business, Service Provider)
Datei-Import mit „gleichzeitig archivieren“	EML, MSG, MBOX, ZIP, MailStore-Export	Nachträglich: beim Import	Verfügbar seit 0.1.0 (jede Edition)

Die vier Wege, die aus einem Postfach oder im Transport eines Anbieters erfassen, gehören zu den Editionen Business und Service Provider; die Community-Version lässt den Erfassungsdienst ruhen und importiert nur Dateien.

Jedes Archivelement trägt seinen Erfassungsweg im Feld source. Suche, Elementdetail, Export und Nachweisbericht nennen ihn, und eine importierte oder zeitnah erfasste Mail erscheint nie als Journal. Das Feld hat fünf Werte: journal, file_import, graph_sync, imap_sync und seit 0.4.4 smtp_forward für weitergeleitete Kopien. In der Oberfläche heißt eine weitergeleitete Kopie Weiterleitung.

Journaling oder zeitnahe Erfassung

Das Produkt nennt die beiden Arten Echt und Zeitnah (im Job-Editor, in der Suche und auf der Archiv-Seite).

Journalisierte Erfassung (eine Exchange-Journalregel, Weiterleitung beim Anbieter) erzeugt die Kopie beim Transport, bevor die Mail in einem Postfach liegt. Kein Nutzer, keine Postfachregel und kein Client kann vorher eingreifen. Der Umschlag eines Journal-Reports nennt alle Empfänger, auch BCC und aufgelöste Verteiler, und auch Mail, die nie in einem Postfach landet oder sofort gelöscht wird, ist erfasst. Das ist der stärkste Nachweis für „vollständig und vor jeder Veränderung erfasst“. Der Preis: Restow muss Mail von außen annehmen (Port 25, ein eigener Hostname mit TLS), und ist Restow länger nicht erreichbar, gibt das sendende System die Zustellung irgendwann auf. Eine weitergeleitete Kopie hat keinen solchen Umschlag: Die Empfänger stehen nur in ihren Kopfzeilen, und BCC-Empfänger sind gar nicht sichtbar, es sei denn, der Anbieter schreibt sie in eine Kopfzeile.

Zeitnahe Erfassung (Graph, IMAP) holt die Mail kurz nach der Zustellung aus dem Postfach. Sie ist nicht vollständig. In dieser Lücke kann eine Mail verschoben oder gelöscht werden. Ein Hold im Microsoft-365-Mandanten schließt die Lücke für gelöschte Mail weitgehend; bei IMAP gibt es dafür nichts Vergleichbares. BCC-Empfänger sieht Restow nur beim Absender, und Mail, die eine Anwendung ohne Kopie in „Gesendete Elemente“ verschickt, fehlt.

Kurz: Journaling beweist jede Mail so, wie sie durch den Server ging; die zeitnahe Erfassung liefert jede Mail so, wie sie kurz danach im Postfach lag. Restow kennzeichnet beides und behauptet für die zeitnahe Erfassung keine Vollständigkeit.

Exchange-Online-Journaling (Business und Service Provider)

Eine Journal-Regel, im Exchange Admin Center von der Administration des Kunden eingerichtet, weist Exchange an, eine Kopie passender Mail (einen Journal-Report) an eine von Restow kontrollierte Adresse zu senden, bevor das Postfach der Empfängerin oder des Empfängers gelesen, geändert oder daraus gelöscht werden kann. Die Regel lässt sich auf alle im Mandanten oder auf ausgewählte Empfänger oder Gruppen beschränken. Einrichtung, Status und Fehlerbehebung stehen unter Exchange-Journaling; dieser Abschnitt beschreibt, was der Weg leistet.

Jeder Mandant hat eine eigene Journal-Adresse, journal+<token>@<Journal-Host>, mit einem zufälligen Token je Mandant, sodass ein Report nicht durch Erraten der Adresse im falschen Mandanten landen kann. Der Empfänger braucht ein eigenes TLS-Zertifikat und startet ohne dieses nicht.
Exchange verlangt eine Adresse für unzustellbare Journal-Reports, bevor Journaling überhaupt funktioniert. Eine Administration richtet sie einmalig beim Einschalten des Journalings ein. Seit 0.4.4 schreibt Restow die Exchange-Online-PowerShell-Befehle für den Connector, dieses Postfach und die Journalregel zum Kopieren und wartet auf den ersten Report.
Ein Journal-Report ist ein Umschlag um die ursprüngliche Nachricht. Restow liest den Umschlag (Absender, Empfänger, Message-ID, einschließlich der BCC-Empfänger, die nur der Umschlag zeigt) und speichert das Original byte-genau (message/rfc822) und den Umschlag als strukturierte Daten.
Ein Report, der sich nicht vollständig lesen lässt, wird trotzdem archiviert und markiert (report-unparseable, report-parse-timeout, report-parse-memory-limit): Restow verwirft nicht still, was es nicht vollständig verstehen kann. Reports werden in eigenen Parser-Prozessen mit Zeit- und Speichergrenze gelesen, nie im API-Prozess; siehe Wie Journal-Reports gelesen werden.
Seit 0.3.1 wird jeder archivierte Report in derselben Transaktion allen geschützten Postfächern des Mandanten zugeordnet, deren Adresse sein Umschlag nennt: als Empfänger, als Absender (gesendete Mail), als Postfach, für das ein Stellvertreter gesendet hat, oder als Postfach, das weitergeleitet hat. Die Adressen werden klein geschrieben mit der primären Adresse, dem Benutzerprinzipalnamen und jedem SMTP-Alias verglichen, den die Verzeichnissynchronisierung speichert; ein IMAP-Konto wird über seinen Login zugeordnet. Ein Report, der kein Postfach des Mandanten nennt, wird trotzdem archiviert und gehört dann nur dem Mandanten: Nichts wird verworfen. Suche, Export und ein Legal Hold je Postfach berücksichtigen zugeordnete Reports. Reports, die vor 0.3.1 eingingen, haben keine Zuordnung.
Eine SMTP-Transaktion liefert in das Archiv genau eines Mandanten: Ein Empfänger eines zweiten Mandanten wird mit 452 beantwortet und vom Absender getrennt zugestellt.
Der Empfänger prüft den Absender noch nicht (SPF, Microsoft-Adressbereiche). Er nimmt nur bekannte Journal- und Archivadressen an, begrenzt die Rate je Absender-IP-Adresse und je Adresse (seit 0.4.4 standardmäßig 600 Verbindungen und 300 Zustellungen je Minute) und weist Reports über JOURNAL_MAX_SIZE_MB (standardmäßig 150 MB) ab.
Journaling sieht Mail erst ab dem Moment, in dem die Regel aktiv ist. Mail, die vorher schon im Postfach lag, wird auf diesem Weg nicht erfasst; die Graph-Erfassung übernimmt sie einmalig.

Graph-Erfassung (Microsoft 365, seit 0.4.4)

Restow abonniert für jedes archivierte Postfach die Microsoft-Graph-Änderungsbenachrichtigungen über neue Mails und holt jede neue Mail kurz nach der Zustellung. Nötig ist nur die App-Zustimmung, die die Sicherung ohnehin nutzt (Mail.ReadWrite, Anwendungsberechtigung): keine neue Berechtigung, kein Port 25, kein Mail-Hostname, keine Journalregel. Einzelheiten und die Netzwerkseite stehen unter Quellen verbinden.

Ein Abonnement je archiviertem Postfach, angelegt und verlängert in $batch (höchstens 20 je Anfrage und eine Anfrage je Sekunde und Microsoft-Mandant), verlängert, wenn weniger als ein Tag übrig ist, neu autorisiert, wenn Microsoft darum bittet, nach einer Entfernung oder einem Ablauf und bei einem Wechsel der Entra-App neu angelegt (ein Abonnement gehört der App, die es angelegt hat).
Eine Benachrichtigung trägt keine Mail. Sie sagt Restow nur, dass eine Mail existiert; der Worker holt die Mail mit eigenem Token bei Graph, innerhalb von Minuten. Entwürfe werden übersprungen (eine gesendete Mail kommt als eigene Nachricht in „Gesendete Elemente“). Unveränderliche Nachrichten-IDs verhindern, dass eine verschobene Mail doppelt erfasst wird.
Ein regelmäßiger Abgleich holt nach, was eine verlorene Benachrichtigung verpasst hat: ein Delta über jeden Ordner, versteckte eingeschlossen, und die wiederherstellbaren Löschungen, alle 6 Stunden (ARCHIVE_GRAPH_CATCHUP_MINUTES, 360) und sofort nach einer verpassten Benachrichtigung.
Ohne öffentliche HTTPS-URL kann Microsoft keine Benachrichtigungen senden, und jedes Postfach wird alle 15 Minuten geprüft (ARCHIVE_GRAPH_POLL_MINUTES). Die Archiv-Seite nennt den Grund.
Gelöschte Mail. Restow liest den Ordner der Löschungen in den Wiederherstellbaren Elementen. Was ein Nutzer endgültig löscht, bevor Restow es geholt hat (Sekunden bis Minuten mit Benachrichtigungen), kann fehlen, und nur Journaling erfasst vor der Zustellung. Damit auch schnell gelöschte Mail erfasst wird, sollte im Mandanten eine Aufbewahrungsrichtlinie oder ein Litigation Hold aktiv sein. Graph v1.0 kann das Restow nicht mitteilen, deshalb bestätigt eine Administration es auf der Archiv-Seite, mit den Exchange-Online-PowerShell-Befehlen, die es prüfen.
Grenzen. Graph kann eine Mail über etwa 150 MB nicht exportieren: Eine solche Mail wird protokolliert und nicht archiviert.

Weiterleitung an die Journal-Adresse (IMAP-Anbieter, Google Workspace; seit 0.4.4)

Für Anbieter ohne Exchange-Journaling schickt der Anbieter serverseitig eine Kopie jeder ein- und ausgehenden Mail an Restow: eine BCC-Regel in Postfix, mailcow oder beim Hoster, ein Sieve redirect :copy oder die Routing-Regel „Weitere Empfänger hinzufügen“ in Google Workspace. Der Empfänger nimmt solche Kopien neben Exchange-Journalberichten an. Die Kopie entsteht beim Transport des Anbieters, also wie beim Journaling vor jedem Zugriff des Nutzers.

Zwei Arten von Adresse. Jedes IMAP-Konto kann eine eigene Archivadresse haben, archive+<token>@<Journal-Host>: Eine Kopie an sie gehört genau diesem Konto. Eine Kopie an die Journal-Adresse des Mandanten wird nach ihren Kopfzeilen (From, To, Cc, Delivered-To und weiteren) und nach MAIL FROM zugeordnet; so arbeiten eine Regel für eine ganze Domäne und die Routing-Regel von Google Workspace.
Was einer Kopie fehlt. Es gibt keinen Umschlag wie bei einem Journal-Report. BCC-Empfänger sind nur sichtbar, wenn der Anbieter sie in eine Kopfzeile schreibt, und MAIL FROM ist oft eine SRS-Adresse des Weiterleiters. Die Adresse eines einzelnen Kontos ordnet deshalb sicher zu, die Mandanten-Adresse nur so weit, wie die Kopfzeilen reichen.
Der Empfänger ist derselbe wie beim Journaling: Port 25, ein eigener Hostname, ein TLS-Zertifikat, und STARTTLS ist Pflicht. Der Betreiber richtet ihn einmal für beides ein. Siehe Weitergeleitete Kopien vom Mailanbieter.
Sieve leitet nur eingehende Mail weiter; ausgehende Mail kommt über die IMAP-Archivierung.

IMAP-Archivierung (IMAP- und Google-Workspace-Konten, seit 0.4.4)

Ein laufender Abgleich des Postfachs, der eine Mail erfasst, sobald sie im Postfach liegt. Für Anbieter ohne Weiterleitung ist das die bestmögliche Näherung und wird als solche gekennzeichnet.

Bei der Aktivierung hält Restow fest, wo jeder Ordner steht (UIDVALIDITY und UIDNEXT). Mail bis dahin wird einmalig übernommen; danach liest jeder Durchlauf nur Neues: STATUS je Ordner, zuerst die Metadaten, die Quelle nur von Mail, die das Archiv für dieses Konto noch nicht hält. Eine verschobene Mail oder eine schon weitergeleitete Kopie wird nicht erneut geladen. Ändert sich UIDVALIDITY, wird der Ordner von vorn gelesen, ohne dass etwas doppelt archiviert wird.
Alle Ordner außer Entwürfen. Bei Gmail und Google Workspace werden nur Alle Nachrichten, Spam und Papierkorb gelesen, die jede Mail genau einmal halten.
IDLE, wo der Server es anbietet. Jeder Worker-Prozess beobachtet bis zu ARCHIVE_IMAP_IDLE_MAX Konten (300) mit je einer offenen Verbindung, sodass neue Mail nach Augenblicken bemerkt wird; alle ARCHIVE_IMAP_POLL_MINUTES (5) prüft ein STATUS die übrigen Ordner. Andere Konten werden alle ARCHIVE_IMAP_LOGIN_POLL_MINUTES (10) per Anmeldung abgefragt. Für Anbieter mit knappem Verbindungslimit gibt es an der Quelle die Einstellung Nur in Abständen prüfen.
IMAP-Konten auf einem Microsoft-Host werden wie jedes andere archiviert, aber eine Microsoft-365-Quelle mit Graph oder Journaling erfasst solche Postfächer vollständiger.

Die einmalige Übernahme vorhandener Mail (seit 0.4.4)

Wird ein Weg für ein Postfach eingeschaltet, übernimmt ein Hintergrundjob die Mail, die schon dort liegt, einmalig. Er setzt dort fort, wo er angehalten hat, hält bei einem Update oder Herunterfahren sauber an und wartet, solange der Speicher eines Mandanten das Ziel wechselt. Was er einbringt, ist als Nachträglich erfasst markiert (Markierung captured-late): Die Mail lag vor dem Beginn der Erfassung im Postfach, das Archiv kann also zeigen, wann Restow sie bekam, nicht dass sie vorher niemand geändert hat. Die Archiv-Seite zeigt den Fortschritt.

Ein Element je Mail über alle Wege (seit 0.4.4)

Restow erkennt dieselbe Mail aus mehreren Wegen an der normalisierten Message-ID zusammen mit den exakten Bytes oder einem Hash des Bodys (eine Journal-Kopie und die Postfachkopie unterscheiden sich in den Kopfzeilen, nicht im Body) und behält ein Element. Eine Erfassung, die nicht stärker ist als die vorhandene, wird eine Erfassungszeile an diesem Element, außerhalb der Kette, dazu eine Zuordnung zum Postfach. Eine stärkere Erfassung (echt vor aus dem Postfach vor Import) wird ein neues Element, das die schwächere nennt, die es ersetzt; das schwächere Element bleibt unverändert, weil das Archiv nur anhängbar ist. Dieselbe Message-ID mit anderem Body bleibt zweimal erhalten und trägt die Markierung message-id-conflict. Journal-Reports und importierte Mail bleiben Elemente für sich. Die Suche zeigt die stärkere Erfassung und listet die anderen auf Wunsch (Ersetzte Erfassungen zeigen, includeSuperseded=true bei GET /api/v1/archive/search); siehe Archivierung.

Aus Dateien importierte Mail (jede Edition)

Mail aus einem Altpostfach, das es nicht mehr gibt (EML, MSG, MBOX, ZIP oder ein MailStore-Export), lässt sich in Restow importieren und gleichzeitig archivieren, mit dem Erfassungsweg file_import (Mail-Dateien importieren und exportieren). Das geht in jeder Edition, auch in Community. Sie wird nachträglich erfasst: Die Aufbewahrungsfrist beginnt mit dem Import, nicht mit dem Datum der Mail, und der Schutz des Archivs (nur anhängbarer Speicher, Hash-Kette) beginnt, sobald Restow das Element erfasst. Eine alte Mail, die heute importiert wird, wird ab heute gezählt. Das eigene Sendedatum der Mail bleibt erhalten (in sent_at) und wird in Suche und Anzeige bevorzugt. Eine Nachricht, die für dasselbe Postfach bereits archiviert ist, wird nicht doppelt archiviert.

Der Job-Editor und die Erfassungswege

Der Editor eines Mail-Jobs (Backup-Jobs) erkennt die Art jedes Postfachs im Job (Microsoft 365, IMAP, Google Workspace über IMAP, IMAP auf einem Microsoft-Host) und bietet nur die passenden Wege an: Graph und Exchange-Journaling für Microsoft 365, IMAP-Archivierung und Weiterleitung für IMAP und Google Workspace. Jeder ist als Echt oder Zeitnah gekennzeichnet, mit seiner Edition gesperrt, und je Art ist mindestens einer nötig. Die Vorgaben eines neuen Jobs sind Graph und IMAP-Archivierung. Eine Journal-Adresse wird nur angelegt, solange das Exchange-Journaling für Microsoft-365-Postfächer gewählt ist, und Archivadressen für die Weiterleitung nur auf Anforderung. Ein Job aus der Zeit vor 0.4.4 behält, was er tat: Exchange-Journaling für Microsoft 365 und für IMAP und Google Workspace noch keinen Weg, bis eine Administration einen wählt.

Was die Archiv-Seite zeigt (Business, seit 0.4.4)

Auf der Archiv-Seite sieht eine Mandanten-Administration den Zustand der Wege: einen Hinweis, den Sie ausblenden können und der die Mail-Jobs nennt, in denen sich Graph oder IMAP-Archivierung einschalten ließe; die Erfassung aus den Postfächern mit ihren Strömen, wie neue Mail bemerkt wird (benachrichtigt, oder im Intervall geprüft mit dem Grund), den Zählern und dem Fortschritt der Übernahme, und eine Tabelle je Postfach mit Neu abgleichen; die Bestätigung des Holds für gelöschte Mail je Microsoft-365-Quelle, mit den PowerShell-Befehlen, die nur lesen und ihn prüfen; die Befehle für das Exchange-Journaling und das Warten auf den ersten Report; und die Weiterleitungsadressen je IMAP-Konto mit der Konfiguration für Postfix, mailcow, Sieve und Google Workspace. Warnungen sagen, wenn die Erfassung stoppt: ein Postfach seit über einer Stunde im Fehler, weitergeleitete Kopien oder Journal-Reports seit 24 Stunden ausgeblieben (das Ereignis archive.failed). Alles steht unter Archivierung.

Manipulationserkennbar: die Hash-Kette

Jedes archivierte Element erhält eine verkettete Prüfsumme: chain_hash = SHA-256(vorheriger_chain_hash || item_hash || received_at). Die Schaltfläche Kette prüfen auf der Archiv-Seite (und GET /api/v1/archive/chain/verify in der API) führt seit 0.3.1 drei getrennte Prüfungen aus und nennt im Ergebnis, was jede abgedeckt hat:

Verkettung. Der Kettenwert jedes Eintrags wird aus seinem Vorgänger neu berechnet. Das erkennt einen geänderten Hash und einen entfernten oder umgestellten Eintrag überall außer ganz am Ende. Geprüft werden die in der Datenbank gespeicherten Prüfsummen; der erste Bruch wird mit seiner Position (ab 1 gezählt) und dem Element genannt.
Tagesanker. Nach jedem UTC-Tag versiegelt ein nächtlicher Lauf des Workers für jeden Mandanten, dessen Archiv an diesem Tag gewachsen ist, einen Anker: das Datum, den Kettenwert des letzten Eintrags des Tages und die Zahl der Einträge, die die Kette bis dahin hatte. Anker sind nur anhängbar, und jeder steht zusätzlich im Worker-Log. Die Prüfung gleicht die Kette mit jedem Anker ab: Sie muss ihn mit demselben Wert an derselben Stelle noch erreichen. Das deckt am Ende der Kette abgeschnittene Einträge auf, was die Verkettung allein nicht kann, weil nichts übrig bleibt, das widersprechen könnte. Einträge, die neuer sind als der letzte Anker, sind noch nicht abgedeckt, und das Ergebnis nennt ihre Zahl.
Stichprobe der Inhalte, auf Wunsch. Kette und Stichprobe der Inhalte prüfen liest bis zu 100 zufällig gewählte Nachrichten aus dem Repository zurück und vergleicht jede mit der Größe und dem SHA-256, die bei der Erfassung festgehalten wurden. Verkettung und Anker betreffen Datenbankzeilen; nur diese Prüfung sieht auf die gespeicherten Nachrichten selbst, und nur auf die Stichprobe. Eine Nachricht, die archiviert wurde, bevor ihr Repository festgehalten wurde, lässt sich nicht vergleichen, und das Ergebnis sagt das.

Jede Prüfung wird ins Audit-Log geschrieben (archive.chain.verified). Das ist mit manipulationserkennbar gemeint: Eine Änderung lässt sich erkennen, sie ist nicht unmöglich. Wer Schreibzugriff auf die Datenbank hat, könnte die ganze Kette samt Ankern neu berechnen. Die Kette allein beweist also nicht, wer ehrlich ist. In 0.4.7 läuft die Prüfung synchron in einer Anfrage; ein Hintergrundlauf mit Fortschritt ist nicht gebaut.

Ein gemeinsamer Weg zum Anhängen (seit 0.4.4). Jeder Schreiber (Journal-Empfänger, Datei-Import, Graph-Erfassung, IMAP-Archivierung, weitergeleitete Kopien) hängt über denselben Weg an die Kette an: Das Original wird hochgeladen, bevor die Sperre der Kette des Mandanten genommen wird, sodass ein großer Report die übrigen Zustellungen des Mandanten nicht mehr aufhält, und unter der Sperre erhält ein Element einen Zeitstempel streng nach dem letzten in der Reihenfolge, in der die Kettenprüfung läuft (Zeit, dann ID). Vorher konnten zwei Schreiber eines Mandanten mit gleichem Zeitstempel die Kette gabeln.

Geplant, nicht in 0.4.7: tägliche externe Anker. Die Anker oben bleiben innerhalb von Restow, in seiner Datenbank und seinem Worker-Log. Geplant ist ein Eintrag aus Datum, aktuellem Kettenwert und Elementanzahl, der dem Betreiber per E-Mail zugestellt und optional an einen externen RFC-3161-Zeitstempeldienst (zum Beispiel freetsa.org) gesendet wird, damit der Zeitstempel des Ankers selbst unabhängig überprüfbar ist. Gegen einen außerhalb von Restow gehaltenen Wert geprüft, ließe sich eine neu berechnete Kette entlarven. Das Audit-Log hat eine eigene Kette mit täglichen Ankern.

Was das Speicherziel durchsetzt

Archivobjekte gehen in den Chunk-Store wie Backup-Objekte: das Original byte-genau und verschlüsselt. Zusätzlich erhält jedes Objekt einen versiegelten Datensatz, eine JSON-Datei je Element unter tenants/<tid>/archive/<jahr>/<monat>/<archive_item_id>.json. Das Archiv ist auf zwei Ebenen geschützt. Die Anwendung hat keinen Code-Pfad, um ein archiviertes Element vor Ablauf seiner Aufbewahrung zu ändern oder zu löschen: Gelöscht wird nur durch den Aufbewahrungslauf nach Fristablauf, für Elemente ohne Legal Hold (ab Business). Das Speicherziel kann eine zweite Ebene hinzufügen, und was es hinzufügt, hängt vom Ziel ab. Das Standard-Archivziel ist das lokale Volume der Installation.

Mit Object Lock auf S3. Der versiegelte Datensatz trägt eine Object-Lock-Aufbewahrung (Compliance-Modus) bis zum Ende der Archiv-Aufbewahrung. Der Nachrichteninhalt liegt in Packs des Chunk-Stores, neben Backup-Daten. Seit 0.4.0 kann eine Administration für ein Repository unveränderbare Backups einschalten, und dann sind auch diese Packs gesperrt, also auch die Inhalte archivierter Mail: für den dort eingestellten Zeitraum (1 bis 3650 Tage), alle 6 Tage verlängert, solange die Packs verwendet werden. Dieser Zeitraum ist eine Einstellung des Repositorys, nicht die Aufbewahrung des Archivs. Object Lock, das der eigenen Aufbewahrung des Archivs folgt, ist geplant.
Ohne Object Lock (lokaler Speicher, NFS, S3 ohne Lock oder ein Repository ohne unveränderbare Backups). Restow erzwingt die Unveränderbarkeit nur auf Anwendungsebene: kein Lösch- oder Änderungspfad im Code und die Kettenprüfung. Wer Zugriff auf die Dateien oder den Server hat, kann sie ändern oder löschen, und die Packs tragen keine Sperre. Die Seite Repositories kennzeichnet solche Ziele mit „Kein Hardware-WORM“ bzw. „Object Lock nicht aktiviert“, die Archiv-Seite sagt, wie der Speicher archivierte Mail schützt, und der Job-Editor sagt es, wenn ein Job archiviert. Object Lock ist keine Voraussetzung für das Archivieren; es ist das, was Sie hinzufügen, wenn der Speicher selbst Änderungen verweigern soll.
Dedupe. Gleiche Inhalte liegen im Chunk-Store einmal je Mandant. Seit 0.4.4 erkennt das Archiv außerdem dieselbe Mail aus mehreren Erfassungswegen (an Message-ID und Inhalt) und behält ein Element, mit einer Erfassungszeile und einer Zuordnung zum Postfach für jede weitere Erfassung; siehe Ein Element je Mail über alle Wege. Journal-Reports und importierte Mail bleiben Elemente für sich.
Das Feld object_lock. Das Feld object_lock eines Archivelements und der Zähler objectLocked in Archivstatus und Nachweisbericht bedeuten „hat ein Fristende“. Sie bedeuten nicht „liegt unter Object Lock“.

Was das praktisch heißt:

Unveränderbarkeit auf Anwendungsebene bedeutet genau das: kein Code-Pfad, um ein archiviertes Element vor Fristablauf zu ändern oder zu löschen, plus die Hash-Kette, um eine Manipulation zu erkennen. Das ist ein echter Schutz gegen alles, was über Restow läuft, aber nicht dieselbe Garantie, die eine speicherseitig erzwungene Schreibsperre gibt.
Auf der Seite Repositories (Mandanten-Einstellungen → Repositories) zeigt ein erfolgreicher Test eines S3-Repositorys, ob der Bucket Object Lock durchsetzt. Ob Backup-Daten und archivierte Inhalte gesperrt werden, ist eine eigene Einstellung auf der Karte des Repositorys, Unveränderbare Backups, aus, bis eine Administration sie einschaltet.
Eingeschaltet, weigert sich der Speicher selbst, die Packs, abgeschlossenen Manifeste und umhüllten Schlüssel vor ihrem Datum zu löschen oder zu überschreiben, auch bei jemandem, der den Speicherschlüssel von Restow hat. Hält jemand, der Restow kontrolliert, die Verlängerung an, läuft das Gesperrte nach dem eingestellten Zeitraum ab. Ein Verzeichnis bekommt nur eine Löschverzögerung, die Restow selbst einhält und die keine Unveränderbarkeit ist, und das Standard-Repository der Installation lässt sich in 0.4.7 nicht unveränderbar machen.
Backups sind ein getrenntes System (siehe Backup vs. Archiv). Ihre Sperre ist eine Einstellung jedes Repositorys und belegt nicht von sich aus, dass ein Archiv oder ein Verfahren die GoBD erfüllt.

Ob das Gesetz tatsächlich WORM im Speziellen verlangt oder auch andere Maßnahmen akzeptiert, steht unter Vorschriften.

Aufbewahrung und Legal Hold

Die Aufbewahrung in 0.4.7 ist für jeden Mandanten ein fester Standard: Archivierte Elemente bleiben 8 Jahre, und die Frist endet am 31. Dezember des Jahres des Eingangs plus 8 Jahre (eine 2026 eingegangene Mail bleibt bis zum 31. Dezember 2034). Die Archiv-Einstellungen zeigen sie (GET /api/v1/archive/retention); keine Oberfläche und keine API setzt eine andere. Das deckt die 6 Jahre für Handelsbriefe und die 8 Jahre für Buchungsbelege ab, nicht die 10 Jahre für Bücher und Jahresabschlüsse; siehe GoBD und Nachweise.
Die gesetzliche Berechnung nach § 147 Abs. 4 AO (und § 257 Abs. 5 HGB) beginnt die Aufbewahrungsfrist mit dem Ende des Kalenderjahres, in dem ein Beleg empfangen oder versendet wurde, nicht mit dem genauen Erfassungsdatum. Das gilt breit, für alles, was § 147 Abs. 1 AO erfasst, nicht nur für Buchungsbelege. Der Standard von Restow lässt die Frist zum Kalenderjahresende beginnen, was der gesetzlichen Mindestfrist entspricht. Ein Start zum Erfassungsdatum würde die Aufbewahrung früher beenden als die gesetzliche Berechnung, um bis zu etwa ein Jahr.
Legal Hold (ab Business) lässt sich auf der Archiv-Seite für einen ganzen Mandanten oder für ein einzelnes Postfach anlegen und aufheben. Er hat einen Grund, die Person, die ihn angelegt hat, und ein Datum, und er wird wie jede andere Aktion, die archivierte Daten berührt, auditiert. Ein Hold blockiert die Löschung vollständig, auch den geplanten Aufbewahrungslauf. Das Aufheben verlangt in der Oberfläche einen Grund, den das Audit-Log festhält (archive.legal_hold.released); die API nimmt eine Freigabe ohne Grund für Clients der ersten Version an, dann hat der Audit-Eintrag keinen. Ein bereits freigegebener Hold wird nicht ein zweites Mal freigegeben (409). Ein Hold auf ein Suchergebnis ist in 0.4.7 nicht verfügbar. Ein Hold je Postfach schützt die Archivelemente, die einem Postfach zugeordnet sind: beim Import archivierte Mail, Journal-Reports, die diesem Postfach zugeordnet sind (seit 0.3.1), und seit 0.4.4 die aus diesem Postfach erfasste Mail und die für es weitergeleiteten Kopien. Reports ohne Zuordnung, dazu gehört jeder Report, der vor 0.3.1 einging, schützt nur ein mandantenweiter Hold.
Ein täglicher Löschlauf (ab Business; die Aufgabe retention, standardmäßig um 04:30) entfernt nur Elemente, die sowohl abgelaufen als auch nicht gehalten sind, und schreibt jede Löschung samt den Hashes des Elements in das hash-verkettete Audit-Log (archive.item.deleted), sodass selbst rechtmäßige Löschung nach Fristablauf nachvollziehbar bleibt. Ohne die Business-Fähigkeit wird aus dem Archiv nie etwas gelöscht.
Die Aufbewahrung endet nicht zwangsläufig starr zur festen Frist: Nach § 147 Abs. 3 AO muss ein Beleg länger aufbewahrt werden, solange er für eine noch nicht bestandskräftige Steuerfestsetzung von Bedeutung ist. Ein Löschlauf, der immer nach der festen Frist löscht, ohne das zu prüfen, könnte zu früh löschen, und der Löschlauf von Restow prüft das nicht. Diese Prüfung vorzunehmen, etwa mit einem Legal Hold, ist die eigene Entscheidung Ihrer Organisation, nichts, was Restow automatisiert.
Geplant: eine Aufbewahrungsrichtlinie je Mandant (wählbar 6, 8, 10 Jahre oder unbegrenzt), optional je Postfach-Gruppe, mit Fristbeginn zum Erfassungsdatum oder, wie § 147 Abs. 4 AO rechnet, zum Ende des Kalenderjahres; und ein Löschprotokoll (Anzahl, Zeitraum, Hashes der gelöschten Objekte) als eigener Eintrag der Kette.

Wahl je Postfach: nur Backup, oder Backup und Archiv

Geplant, nicht in 0.4.7. Nicht jedes Postfach braucht dieselbe Behandlung. Ein geteiltes Postfach wie bestellung@ oder noreply@ mag es wert sein, gesichert zu werden (damit es sich erholen lässt, wenn etwas kaputtgeht), ohne dieselbe dauerhafte Archivierung zu brauchen, die normale Mitarbeiterkorrespondenz aus Beweisgründen erhält. Restow soll so gebaut werden, dass Sie je Postfach wählen können, über denselben Regelmechanismus, den der Backup-Umfang bereits nutzt (alle, eine Gruppe, eine Ausschlussliste, Einzelentscheidungen), ob ein Objekt nur gesichert oder gesichert und archiviert wird, dargestellt als getrennte Spalten Backup und Archiv nebeneinander auf dem Reiter Schutz.

In 0.4.7 gibt es diesen Schalter je Postfach in Restow nicht. Die Frage Was soll dieser Job tun? an einem Mail-Job (siehe Backup-Jobs) schaltet das Archiv für alle Postfächer des Jobs ein, und die Erfassungswege werden je Art von Postfach gewählt, nicht je Postfach. Was über Journaling im Archiv ankommt, bestimmt die Journal-Regel, die Sie in Exchange Online festlegen (alle, oder ausgewählte Empfänger oder Gruppen), was Graph, IMAP-Archivierung und Weiterleitung erfassen, bestimmen die Postfächer der Jobs, die archivieren, und die Regeln beim Anbieter, und der Mail-Import archiviert, was Sie mit der Archiv-Option importieren. Ein Postfach mit tatsächlich geschäftsrelevanter Korrespondenz vom Archiv auszuschließen, bleibt die eigene Entscheidung Ihrer Organisation nach GoBD, nicht etwas, das Restow für Sie entscheidet.

Journaling und Postfach-Sicherung

Journaling ersetzt die Sicherung der Postfächer nicht, und die Sicherung ersetzt das Journaling nicht. Beide laufen unabhängig: Das Archiv ändert keinen Sicherungslauf, lässt keinen aus und dedupliziert keinen; gemeinsam ist nur der Chunk-Store des Mandanten.

Journaling erfasst, was Exchange Online beim Transport sieht, und zwar in dem Moment, in dem die Mail durch den Transport geht:

ein- und ausgehende Mail, intern und extern, BCC-Empfänger über den Umschlag, sofern die Journalregel diese Nachrichten erfasst (Nachrichtentyp „Alle Nachrichten“ für alle Absender und Empfänger, siehe Exchange-Journaling). Eine Regel nur für externe Mail oder nur für bestimmte Benutzer erfasst interne Mail bzw. die übrigen Postfächer nicht;
den Stand beim Versand: Was ein Nutzer danach ändert, verschiebt oder löscht, ändert die Kopie im Archiv nicht.

Journaling erfasst nicht:

Kalender, Kontakte, Aufgaben und Notizen, auch keine Termin-Antworten als Postfachobjekte (eine Einladung, die als Mail transportiert wird, liegt als Mail im Archiv);
Entwürfe und alles, was nie versendet wurde;
die Ordnerstruktur, den Ordner einer Mail, Gelesen- und Kennzeichnungsstatus, Kategorien und spätere Verschiebungen;
spätere Änderungen und Löschungen: Das Archiv zeigt den Stand beim Transport, nicht den aktuellen Stand des Postfachs, und kann ein Postfach nicht in einen früheren Zustand zurückversetzen (Wiederherstellung in die ursprünglichen Ordner);
Mail, die vor der Aktivierung des Journalings im Postfach lag (Altbestand, siehe Grenzen);
Mail, die nicht durch den Exchange-Online-Transport geht: von außen direkt ins Postfach importiert (PST-Import, Migration, Graph oder IMAP), oder die der Transport abweist bzw. in die Quarantäne legt, bevor die Journalregel greift;
Reports, die Restow nicht erreichen (Connector, Firewall, Zertifikat): Exchange Online schickt sie an das Postfach für nicht zustellbare Journalberichte, nicht ins Archiv.

Graph-Erfassung und IMAP-Archivierung erfassen aus dem Postfach, sehen eine Mail also erst nach der Zustellung, in dem Stand, den sie dann hat. Auch sie ersetzen die Sicherung nicht: Sie erfassen weder Kalender und Kontakte noch die Ordnerstruktur, und eine Wiederherstellung in die ursprünglichen Ordner bleibt Aufgabe der Sicherung. Was Sicherung und Archiv jeweils festhalten, ist dieselbe Frage wie beim Journaling, nur mit einer Lücke zwischen Zustellung und Erfassung.

Die Postfach-Sicherung erfasst Mail, Kalender und Kontakte mit Ordnern und Status zum Zeitpunkt des Laufs und stellt sie wieder her. Sie sieht nicht, was zwischen zwei Läufen eintrifft und wieder gelöscht wird, und ist nicht unveränderbar: Sicherungsstände laufen nach ihrer Aufbewahrungsrichtlinie ab.

Wann was:

Wiederherstellen können (gelöschte Mail, ganze Ordner, Kalender, ein Postfach nach einem Fehler oder Angriff): Postfach-Sicherung. Sie ist immer nötig.
Nachweisen können (GoBD, Aufbewahrungsfristen, Legal Hold, die Mail vor jeder Änderung durch Nutzer): das Archiv, zusätzlich zur Sicherung. Journaling oder Weiterleitung beim Transport ist der stärkste Weg; Graph und IMAP-Archivierung erfassen aus dem Postfach und sind nicht vollständig.
Ist das Journaling für einen Mandanten aktiv, ist neue Mail ab ihrem Eingang im Archiv erfasst (mit Graph oder IMAP-Archivierung: kurz danach). Eine seltenere Sicherung (zum Beispiel alle 8 Stunden oder täglich statt stündlich) verkleinert dann nur das Fenster, in dem Kalender, Ordner und Status verloren gehen können, nicht die Erfassung der Mail, und sie belastet Microsoft 365 weniger. Restow stellt die Häufigkeit nicht selbst um: Der Job-Editor schlägt Alle 8 Stunden sichern vor und übernimmt es erst auf Klick, siehe Backup-Jobs.

Suche, Export und Nachweis

Suche (jede Edition, auf der Archiv-Seite für Mandanten-Administrationen): Volltextsuche über den Betreff, die Adressen (Absender und Empfänger) und, bei importierter Mail, aus dem Postfach erfasster Mail und weitergeleiteten Kopien, den Nachrichtentext (die ersten 200.000 Zeichen; sehr lange Texte können gekürzt sein), mit seitenweiser Anzeige der Treffer und Filtern nach Absender, Datum, Postfach und „mit Anhang“. Der Inhalt von Anhängen wird nicht durchsucht (keine Extraktion aus PDF, DOCX oder XLSX), und der Nachrichtentext von Journal-Reports wird in 0.4.7 nicht indiziert, journalisierte Mail ist also über Betreff und Adressen auffindbar, und ein ohne seine Angaben archivierter Report gar nicht. Verwendet wird die PostgreSQL-Volltextsuche mit der Konfiguration simple: kein Stemming, keine Sprachanalyse. Es suchen nur die Administrationen des Mandanten. Ein Treffer nennt seinen Erfassungsweg und seit 0.4.4 die anderen Wege, die dieselbe Mail erneut erfasst haben, und ob sie nachträglich erfasst wurde; eine Erfassung, die ein stärkerer Weg ersetzt hat, ist ausgeblendet, es sei denn, Sie wählen Ersetzte Erfassungen zeigen. Eine archivierte Nachricht lässt sich in Restow lesen und als .eml herunterladen (seit 0.3.1). Suchen, jedes gelesene Element und jeder Download werden im Audit-Log festgehalten.
Rollen (geplant): Eine Mandanten-Administration soll mandantenweit mit rollenbezogenen Regeln suchen können (selbst auditiert); ein Endnutzer soll ausschließlich im eigenen Postfach suchen können; eine Provider-Administration soll eine explizite, vom Mandanten erteilte Vier-Augen-Freigabe brauchen, bevor sie überhaupt im Archiv eines Kunden suchen kann. In 0.4.7 ist das Archiv für Mandanten-Administrationen da.
Export (jede Edition): Archivierte Mail lässt sich als EML-Dateien in einer ZIP-Datei mit der ursprünglichen Ordnerstruktur, einer MANIFEST.csv und einer SHA256SUMS-Datei oder als MBOX exportieren. Ein Worker-Job baut die Datei, sie lässt sich 24 Stunden herunterladen, und jede Anfrage und jeder Download wird ins Audit-Log geschrieben. Der Export der aktuellen Suche lässt ersetzte Erfassungen aus, wie die Suche, er enthält also genau die Treffer, die die Suche zählt. Der Export ist ohne Restow lesbar. Siehe Mail-Dateien importieren und exportieren. Der Export zur Weitergabe an eine Prüferin oder einen Prüfer, der zusätzlich eine CHAIN.txt der relevanten Kettenwerte enthält, ist geplant.
Nachweisbericht (jede Edition, als JSON über die Integrations-API): GET /api/v1/archive/report (Scope archive:read, höchstens 366 Tage, standardmäßig 30 Tage, mit from und to) liefert den Mandanten, den Zeitraum, Anzahl und Größe der Elemente, die Elemente je Erfassungsweg, die Tagesanker des Zeitraums, die für den Mandanten gespeicherten Aufbewahrungsrichtlinien und die Legal Holds im Zeitraum. GET /api/v1/archive/status liefert die aktuellen Zahlen je Erfassungsweg, die Kettenanker, die Aufbewahrungsrichtlinien und die aktiven Legal Holds. Zwei Dinge sind wichtig: Der Kettenzustand steht in beiden in 0.4.7 auf not_verified, weil keiner der Aufrufe die Kettenprüfung ausführt (nutzen Sie die Archivprüfung, siehe oben), und die eingebaute Vorgabe von 8 Jahren ist nicht als Richtlinie gespeichert, ein Mandant mit der Vorgabe zeigt dort also unter Umständen keine Richtlinie (GET /api/v1/archive/retention zeigt die geltende Frist). Das Lesen des Berichts wird auditiert. Der Vertrag bleibt bei 1.5.0: Weitergeleitete Kopien zählen in den Gesamtzahlen, werden aber nicht als eigener Weg aufgeführt, und graphSync und imapSync melden die neuen Wege. Einen PDF-Bericht und eine Oberfläche dafür gibt es noch nicht.
Geplant: Suche in Anhängen (PDF, DOCX, XLSX, TXT) und nach Größe; Self-Service-Suche der Endnutzer im eigenen Postfach; die oben beschriebene Freigabe für Provider-Administrationen; CHAIN.txt im Export; der Nachweisbericht als signiertes PDF in der Oberfläche (Mandant, abgedeckter Zeitraum, Elementanzahl, Speicherziel, Ergebnis der Archivprüfung, Aufbewahrungsrichtlinie, Löschlauf-Protokolle und eine Signatur über den Bericht selbst).

Bekannte Probleme der Erfassungswege (seit 0.4.4)

Die Erfassungswege wurden gegen simulierte Dienste getestet (eine simulierte Graph-API, einen simulierten IMAP-Server und den Dovecot des Release-Smokes, für die Weiterleitung den Empfänger selbst), nicht gegen einen echten Microsoft-365- oder Google-Workspace-Mandanten, Postfix, mailcow oder Hoster. Holds in einem Microsoft-365-Mandanten werden nicht erkannt, und von den Wiederherstellbaren Elementen wird nur der Ordner der Löschungen gelesen, Mail, die endgültig gelöscht wurde, bevor Restow sie geholt hat, kann also fehlen. Graph kann Mail über etwa 150 MB nicht exportieren. Der Empfänger prüft den Absender nicht, und seine Grenzen zählen je api-Prozess. IMAP-Quellen mit OAuth2 lassen sich noch nicht anlegen. Weitergeleitete Kopien zählen in den Gesamtzahlen der Integrations-API, sind aber kein eigener Weg. Die Liste steht unter Archivierung.

Verfahrensdokumentation (geplant)

Die Verfahrensdokumentation ist geplant; Restow 0.4.7 erzeugt sie nicht. Gedacht ist ein Dokument je Mandant, aus Konfiguration und Vorlage erzeugt, mit Systembeschreibung, Erfassungswegen, Speicherort, Verschlüsselung, Zugriffsrechten, Aufbewahrung, Löschverfahren, Kontrollen (Archivprüfung, Scrub), Verantwortlichen und Änderungshistorie. Es käme als Markdown und PDF, versioniert und mit Datum. Es gehört zur Prüfungsfähigkeit, es ist keine Kür. Das vollständige Dokument samt Ihrer organisatorischen Prozesse bleibt die eigene Verantwortung Ihrer Organisation.

Weiterlesen

Archivierung: die administrationsseitige Zusammenfassung und der aktuelle Stand.
Exchange-Journaling: die Einrichtung, Schritt für Schritt.
Quellen verbinden: was Graph-Erfassung, IMAP-Archivierung und weitergeleitete Kopien von Microsoft 365, vom Mailanbieter und von Ihrem Netzwerk brauchen.
Vorschriften: welche Anforderungen dieses Design adressiert, und ob WORM-Speicher tatsächlich erforderlich ist.
GoBD und Nachweise: die deutschrechtlichen Details hinter den GoBD-Anforderungen „unveränderbar“ und „zeitgerecht“, und was Restow nicht behauptet.
Backup vs. Archiv: warum das überhaupt getrennte Systeme sind.
Unveränderbare Backups: S3 Object Lock und die Löschverzögerung für die Backup-Daten eines Repositorys.