Archivierung

Das Archiv ist ab 0.1.0 enthalten, in jeder Edition, auch in Community. In jeder Edition wird es durch den Mail-Import mit der Option, gleichzeitig zu archivieren, gefüllt. Seit 0.4.4 kommt mit einer Lizenz Business oder Service Provider die Erfassung aus den Postfächern selbst und aus Kopien hinzu, die ein Mailanbieter weiterleitet, neben dem Exchange-Online-Journaling: Microsoft-365-Postfächer über Graph-Änderungsbenachrichtigungen, IMAP- und Google-Workspace-Konten über die IMAP-Archivierung mit IDLE und weitergeleitete Kopien im Transport des Anbieters. Journal- und Weiterleitungs-Empfang per SMTP, durchgesetzte Aufbewahrung und Legal Hold brauchen ebenfalls diese Lizenz. Was unten als geplant markiert ist, ist noch nicht in 0.4.7; die Roadmap nennt, was als Nächstes und was später kommt.

Wofür das Archiv da ist

Backup und Archiv lösen unterschiedliche Probleme. Siehe Backup vs. Archiv, falls Sie diese Seite noch nicht gelesen haben. Kurz gesagt: Backup ist zum Zurückholen da, das Archiv zum Bewahren manipulationserkennbarer Nachweise geschäftlicher E-Mails, für den GoBD-konformen Einsatz ausgelegt (siehe GoBD und Nachweise; dort stehen auch die deutschen Aufbewahrungsfristen, es ist keine Rechtsberatung). Das vollständige technische Konzept (Erfassungswege, Journaling im Detail, die Hash-Kette, was das Speicherziel durchsetzt, Aufbewahrung und Legal Hold) steht unter Archivierung und Journaling; diese Seite ist die Zusammenfassung und der Stand.

Archiv im Mail-Job

Der Editor eines Mail-Jobs fragt zuerst Was soll dieser Job tun? (seit 0.4.2): Sichern, Archivieren oder Sichern und archivieren, Letzteres die Vorgabe für einen neuen Job. Archivieren und Sichern und archivieren schalten das Archiv für die Postfächer des Jobs ein. Archivieren allein sichert nicht nach Zeitplan: Der Job hat dann keinen Zeitplan, und ein von Hand gestarteter Lauf sichert trotzdem. Mit dem Archiv neben der Sicherung schlägt der Editor vor, alle 8 Stunden statt häufiger zu sichern; das ist nur ein Vorschlag. Ein Maschinen-Job kann nicht archivieren. Object Lock ist keine Voraussetzung; ohne Object Lock sagt der Editor, dass das Archiv dann nur auf Anwendungsebene unveränderbar ist.

Seit 0.4.4 erkennt der Editor die Art der Postfächer des Jobs und bietet nur die passenden Erfassungswege an, unter So gelangen E-Mails ins Archiv:

Art des Postfachs	Wege im Editor
Microsoft-365-Postfächer	Microsoft Graph (zeitnah), Exchange-Journaling (echt)
IMAP-Konten	IMAP-Archivierung (zeitnah), Weiterleitung an die Archivadresse (echt)
Google Workspace (IMAP)	IMAP-Archivierung (zeitnah), Routing an die Archivadresse (echt)

Jeder Weg ist als Echt oder Zeitnah gekennzeichnet; ein Weg, den die Edition nicht enthält, ist gesperrt und nennt die Edition. Ein Job mit Postfächern verschiedener Art zeigt die Wege je Art; je Art ist mindestens ein Weg nötig, sonst wird der Job abgelehnt (siehe Backup-Jobs). Ein neuer Job und ein Job, der das Archivieren einschaltet, starten mit den Vorgaben: Graph für Microsoft 365 und IMAP-Archivierung für IMAP und Google Workspace, jeweils mit einer einmaligen Übernahme der Mail, die schon im Postfach liegt. OneDrives, SharePoint-Websites und importierte Postfächer haben nichts zu erfassen.

Jobs, die schon vor dem Update archiviert haben, arbeiten genau wie vorher. Es startet nichts von selbst: Ein Microsoft-365-Postfach eines solchen Jobs bleibt beim Exchange-Journaling allein, und seine IMAP- und Google-Workspace-Konten haben noch keinen Weg und warten auf Ihre Wahl. Einzelheiten stehen unter Update auf 0.4.4.

Das Anhalten eines Mail-Jobs hält nur seine Sicherungen nach Zeitplan an. Die Archivierung läuft weiter, und die Rückfrage beim Anhalten sagt das. Sie endet nur, wenn Sie im Job das Archivieren oder einen Erfassungsweg ausschalten; der Editor fragt dann vorher nach, weil neue Mail dieser Postfächer ab dann nicht mehr archiviert wird. Das bisherige Archiv bleibt unverändert bis zum Ende seiner Aufbewahrung.

Erfassungswege

Weg	Mailquelle	Stärke	Stand	Wert von `source`
Exchange-Online-Journaling	Microsoft 365	Echt: beim Transport, vor der Zustellung	Verfügbar seit 0.1.0 (Business, Service Provider)	`journal`
Graph-Erfassung	Microsoft 365	Zeitnah: kurz nach der Zustellung aus dem Postfach	Verfügbar seit 0.4.4 (Business, Service Provider)	`graph_sync`
Weiterleitung an die Archivadresse	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)	`smtp_forward`
IMAP-Archivierung	Jedes IMAP-Konto, auch Google Workspace	Zeitnah: aus dem Postfach, laufend	Verfügbar seit 0.4.4 (Business, Service Provider)	`imap_sync`
Datei-Import mit „gleichzeitig archivieren“	EML, MSG, MBOX, ZIP, MailStore-Export	Nachträglich: beim Import	Verfügbar seit 0.1.0 (jede Edition)	`file_import`

Echt (Journaling und Weiterleitung) erzeugt die Kopie, bevor die Mail in irgendeinem Postfach liegt; kein Nutzer, keine Postfachregel und kein Client kann vorher eingreifen. Zeitnah (Graph und IMAP-Archivierung) holt die Mail kurz nach der Zustellung aus dem Postfach. Zeitnahe Erfassung ist nicht vollständig: In der Lücke zwischen Zustellung und Erfassung kann eine Mail verschoben oder gelöscht werden, BCC sieht Restow nur beim Absender, und Mail, die eine Anwendung ohne Kopie in „Gesendete Elemente“ verschickt, fehlt. Restow kennzeichnet die Wege und behauptet für die zeitnahen keine Vollständigkeit. Was der Unterschied bedeutet, steht unter Archivierung und Journaling.

Suche, Detail, Export und Nachweisbericht nennen den Weg jedes Elements, und eine importierte oder zeitnah erfasste Mail erscheint nie als Journal.

Was jeder Weg braucht

Graph-Erfassung. Keine neue Microsoft-Berechtigung: Das Mail.ReadWrite, das die Sicherung ohnehin hat, genügt. Damit Microsoft Änderungsbenachrichtigungen senden kann, muss die öffentliche URL der Installation https:// auf Port 443 sein und von Microsoft erreichbar; sonst wird jedes Postfach alle 15 Minuten geprüft. Siehe Archiv-Erfassung aus Microsoft-365-Postfächern und Netzwerk und Ports.
IMAP-Archivierung. Eine Passwort-Anmeldung am Postfach, eine offene Verbindung je Konto (IMAP IDLE), wo der Server es anbietet. Siehe IMAP-Archivierung und Google-Workspace-Konten.
Weiterleitung. Regeln beim Mailanbieter und der Journal-Empfänger auf Ihrer Seite: Port 25, ein eigener Hostname, ein TLS-Zertifikat. Siehe Weitergeleitete Kopien vom Mailanbieter.
Exchange-Journaling. Ein Connector und eine Journalregel in Microsoft 365 und derselbe Empfänger. Siehe Exchange-Journaling.

Der empfohlene Job archiviert (seit 0.4.7)

Empfohlenen Job anlegen und Alles ohne Job schützen schalten das Archiv jetzt ein, wo die Installation die Erfassung aus dem Postfach anbietet und der Mandant Postfächer oder Konten hat, die ein Archiv erfassen kann: Ein neuer Mail-Job über alle Objekte sichert und archiviert, und ein Mail-Job über alle Objekte, der noch nicht archiviert, wird auf Archivierung umgeschaltet, mit seinen Zeitplänen. Der Klick nimmt die Standard-Erfassungswege (Microsoft Graph für Microsoft-365-Postfächer, IMAP-Abgleich für die übrigen Konten), und die Übernahme vorhandener Mail gilt wie bei jedem Job, der Archivierung einschaltet. Er ändert nie einen Mail-Job über ausgewählte Objekte oder einen, dessen Erfassungswege von Hand gewählt wurden. Journaling und Weiterleitung bleiben eine Wahl im Job-Editor. Siehe Backup-Jobs.

IMAP-Erfassung (seit 0.4.7)

In der IMAP-Archiv-Erfassung hält eine Nachricht, die der Server ablehnt oder nicht liefert, ihren Ordner oder den ganzen Durchlauf nicht mehr auf: Die anderen Nachrichten werden erfasst, und nach drei Durchläufen gibt die Erfassung diese Nachricht auf. Ein abgelehnter Ordner kostet nur diesen Ordner für diesen Durchlauf. Ordner, die ein Durchlauf nicht erreicht hat, behalten ihren Zustand, sodass ältere Mail nach einem unterbrochenen Durchlauf nicht mehr übersprungen wird. Ein Limit des Kontos beendet den Durchlauf mit erhaltenem Zustand. Eine Überwachung, die der Server mit NO bei EXAMINE oder IDLE ablehnt, wird nach Minuten wiederholt (sich bis auf eine Stunde verdoppelnd), statt einen Tag lang für einen Server ohne IDLE gehalten zu werden. Eine Nachricht, auf die die Erfassung verzichtet hat, steht nur im Log des Workers, nicht in der Oberfläche.

Die einmalige Übernahme vorhandener Mail

Die Erfassung beginnt, wenn ein Weg eingeschaltet wird. Mail, die vorher schon im Postfach lag, übernimmt ein Hintergrundjob einmalig; er setzt dort fort, wo er angehalten hat (im Verlauf erscheint er als Archiv-Sync). Er beginnt, sobald der Strom des Postfachs läuft, bei Graph seitenweise durch das Postfach, bei IMAP bis zur Position jedes Ordners, die bei der Aktivierung festgehalten wurde. Er hält bei einem Update oder einem Herunterfahren sauber an und wartet, solange der Speicher eines Mandanten das Ziel wechselt. Auf diesem Weg übernommene Mail ist als Nachträglich erfasst markiert (Markierung captured-late): Sie lag vor dem Beginn der Erfassung im Postfach, das Archiv kann also nicht zeigen, dass sie vorher niemand geändert hat. Die Archiv-Seite zeigt den Fortschritt als „Altbestand übernommen: X von Y Postfächern“.

Das Exchange-Journaling kennt keine Übernahme, weil es Mail nur im Transport sieht. Mail, die vor dem Einschalten der Journalregel im Postfach lag, lässt sich weiterhin über den Datei-Import oder über Graph-Erfassung und IMAP-Archivierung einbringen.

Ein Element je Mail über alle Wege

Dieselbe Mail kann auf mehreren Wegen im Archiv ankommen, zum Beispiel über die Weiterleitung und über die IMAP-Archivierung. Restow erkennt sie an der normalisierten Message-ID zusammen mit den exakten Bytes oder einem Hash des Bodys und behält ein Element:

Eine Erfassung, die nicht stärker ist als das, was das Archiv schon hält, wird eine Erfassung an diesem Element, dazu eine Zuordnung zum Postfach. Ein zweites Element in der Kette entsteht nicht.
Eine stärkere Erfassung wird ein neues Element, das die schwächere nennt, die es ersetzt. Die frühere bleibt unverändert; das Archiv ist nur anhängbar. Die Reihenfolge der Stärke: echt (Journal, weitergeleitete Kopie), dann aus dem Postfach (Graph, IMAP-Archivierung), dann Import.
Dieselbe Message-ID mit anderem Body ist nicht dieselbe Mail: Beide bleiben erhalten, die spätere trägt die Markierung message-id-conflict.
Journal-Reports und importierte Mail bleiben Elemente für sich, aber eine stärkere Erfassung ersetzt eine schwächere trotzdem in der Suche.

Die Suche blendet Erfassungen aus, die ein stärkerer Weg ersetzt hat. Ersetzte Erfassungen zeigen listet sie mit auf (includeSuperseded=true bei GET /api/v1/archive/search). Ein Treffer nennt die anderen Wege, die die Mail erfasst haben („auch über …“), und ob sie nachträglich erfasst wurde, und das Detail verweist in beide Richtungen: Auch erfasst über, Ersetzt und Ersetzt durch. Der Export der aktuellen Suche folgt der Suche: Ersetzte Erfassungen sind nur im Export, wenn die Suche sie zeigt, er enthält also genau die Treffer, die die Suche zählt.

Die Archiv-Seite

Auf der Seite Archiv (Mandanten-Administrationen) zeigen die Wege ihren Zustand. Mit einer Lizenz Business oder Service Provider hat sie diese Teile; ohne sie nennen Editor und Seite stattdessen die Edition.

Hinweise. Nach dem Update steht ein Hinweis, den Sie ausblenden können: Neu: Erfassung über Microsoft Graph bzw. IMAP verfügbar. Er nennt die Mail-Jobs, in denen Graph für Microsoft-365-Postfächer aus ist oder für IMAP- oder Google-Workspace-Konten noch kein Weg gewählt ist, jeweils mit Job öffnen. Der Erfassungsstatus listet diese Jobs noch einmal unter Wartet auf einen Erfassungsweg.

Erfassung aus den Postfächern. Eine Karte je Weg, Microsoft Graph und IMAP-Archivierung, gekennzeichnet als Zeitnah. Sie zeigt die Ströme (einer je archiviertem Postfach und Weg: laufend, übernimmt den Altbestand, wartet auf den Start, mit Fehler, angehalten, ausgeschaltet), wie neue Mail bemerkt wird, den Zeitpunkt der letzten Erfassung, die Zähler der letzten 24 Stunden und 7 Tage (neue Elemente und Erfassungen von Mail, die das Archiv schon hatte), den Fortschritt der Übernahme und wie viele Mails der letzten 7 Tage nachträglich erfasst wurden. Wie neue Mail bemerkt wird, steht als „Benachrichtigt von Microsoft“ oder „Überwacht mit IDLE“, und eine Zeile nennt, warum Postfächer stattdessen im Intervall abgefragt werden:

Grund	Bedeutung
`graph.notification_url_unavailable`	Microsoft erreicht diese Installation nicht über öffentliches HTTPS und kann deshalb keine Benachrichtigungen senden.
`graph.subscription_failed`	Microsoft hat das Abonnement der Benachrichtigungen abgelehnt (wird stündlich erneut versucht).
`imap.idle_unsupported`	Der Mailserver unterstützt IDLE nicht.
`imap.idle_disabled`	IDLE ist für diese IMAP-Quelle ausgeschaltet.
`imap.idle_budget`	Dieser Worker überwacht bereits so viele Konten mit IDLE, wie er darf.

Die Tabelle Je Postfach filtert nach Weg und Status (Wartet, Übernahme, Laufend, Angehalten, Aus, Fehler) und hat die Aktion Neu abgleichen: Das Postfach wird beim nächsten Durchlauf vollständig neu gelesen. Sie wird ins Audit-Log geschrieben (archive.capture.resync_requested).

Gelöschte E-Mails in Microsoft 365. Graph erfasst E-Mails kurz nach der Zustellung. Damit auch sofort gelöschte E-Mails erfasst werden, sollte eine Aufbewahrungsrichtlinie oder ein Litigation Hold gelöschte E-Mails im Microsoft-365-Mandanten halten. Graph v1.0 bietet keinen Weg, das zu lesen, Restow kann es also nicht erkennen: Für jede Microsoft-365-Quelle zeigt die Seite Hold nicht bestätigt, bis eine Administration es prüft und Hold bestätigen wählt. Die Bestätigung steht mit dem Namen der Administration im Audit-Log (archive.hold.confirmed), Bestätigung zurücknehmen nimmt sie zurück (archive.hold.unconfirmed), und Restow prüft die Aussage nicht nach. Die Seite zeigt Befehle, die nur lesen und Holds und Aufbewahrungsrichtlinien prüfen; eine Administration des Microsoft-365-Mandanten führt sie in Exchange Online PowerShell und Security & Compliance PowerShell aus, Restow führt keinen davon aus:

Connect-ExchangeOnline
Get-Mailbox -ResultSize Unlimited | Select-Object UserPrincipalName, LitigationHoldEnabled, LitigationHoldDuration, InPlaceHolds
Get-Mailbox -ResultSize Unlimited | Where-Object { -not $_.LitigationHoldEnabled -and $_.InPlaceHolds.Count -eq 0 } | Select-Object UserPrincipalName
Get-OrganizationConfig | Select-Object -ExpandProperty InPlaceHolds
Connect-IPPSSession
Get-RetentionCompliancePolicy -DistributionDetail | Where-Object { $_.ExchangeLocation } | Select-Object Name, Enabled, Mode, DistributionStatus, ExchangeLocation, ExchangeLocationException
Get-RetentionComplianceRule | Select-Object Policy, Name, RetentionDuration, RetentionComplianceAction

Exchange-Journaling. Neben dem Status und der Journal-Adresse (Exchange-Journaling) hat der Abschnitt fertige Befehle für Exchange Online PowerShell für den Connector, das Postfach für nicht zustellbare Journalberichte und die Journalregel. Sie erscheinen, sobald Sie dieses Postfach angeben. Auf einen Report warten prüft danach alle 5 Sekunden, ob nach dem Einrichten der Regel ein Report angekommen ist, und der Abschnitt nennt den ersten Report, der angekommen ist.

Weiterleitung an das Archiv. Für IMAP-Konten, deren Job die Weiterleitung gewählt hat: die Archivadresse jedes Kontos (archive+<token>@<Journal-Host>), ein Status (Kopien kommen an, Seit mehr als 24 Stunden keine Kopie, Noch keine Kopien, Noch keine Adresse), die letzte Kopie und die Zähler für 24 Stunden und 7 Tage. Adresse anlegen stellt die Adresse einmalig aus (auditiert als archive.forward.address_created), Sie kopieren sie in die Regel des Anbieters, und Adresse erneuern (mit Rückfrage) ersetzt sie: Die alte Adresse ist sofort ungültig, Kopien an sie werden abgewiesen, ändern Sie die Regel beim Anbieter also gleich (auditiert als archive.forward.address_rotated, nur mit Fingerabdruck). Die Reiter Postfix, mailcow, Sieve und Google Workspace zeigen die Konfiguration für die Adressen der Konten. Wie das funktioniert und was der Betreiber einrichtet, steht unter Weitergeleitete Kopien vom Mailanbieter.

Warnungen, wenn die Erfassung stoppt

Das Ereignis Archiv-Abgleich fehlgeschlagen (archive.failed) meldet jetzt auch, dass die Erfassung gestoppt hat. Glocke, Regeln und Mail sagen, welcher von drei Fällen es ist, und führen zu dessen Abschnitt der Archiv-Seite:

Warnung	Ausgelöst, wenn
Archiv-Erfassung seit über einer Stunde fehlerhaft	Die Erfassung eines Postfachs (Graph oder IMAP) steht seit mehr als einer Stunde im Fehler.
Seit 24 Stunden keine weitergeleiteten Kopien	Kopien eines IMAP-Kontos kamen vorher an, seit 24 Stunden keine, und sein Job will sie.
Seit 24 Stunden keine Journal-Reports	Die Journal-Adresse des Mandanten hat vorher Reports empfangen, seit 24 Stunden keinen.

Jede Warnung kommt, nachdem vorher etwas empfangen wurde, und einmal je Abschnitt: Sie wiederholt sich nicht, bis die Erfassung, die Kopien oder die Reports wieder funktioniert haben. Ein angehaltener Job erfasst weiter, seine Konten zählen also mit. Siehe Benachrichtigungen und Berichte.

Verfügbar in 0.4.7

In jeder Edition, auch in Community

Aus Dateien importierte Mail, mit Archivierung: Wenn Sie ein Altpostfach aus EML, MSG, MBOX, ZIP oder einem MailStore-Export importieren, können Sie es gleichzeitig archivieren (Erfassungsweg file_import). Die Aufbewahrung beginnt mit dem Import, nicht mit dem Datum der Mail, und das eigene Datum der Mail bleibt erhalten und wird in Suche und Anzeige verwendet. Der Schutz des Archivs (nur anhängbarer Speicher, Hash-Kette) gilt ab dem Moment, in dem Restow das Element hat. Siehe Mail-Dateien importieren und exportieren.
Archiv-Seite für Mandanten-Administrationen: Suche über den Betreff, die Adressen und, bei importierter Mail, aus dem Postfach erfasster Mail und weitergeleiteten Kopien, den Nachrichtentext (der Inhalt von Anhängen wird nicht durchsucht), mit seitenweiser Anzeige der Treffer und Filtern nach Absender, Datum und Postfach. Seit 0.3.1 lässt sich eine archivierte Nachricht in Restow lesen und als .eml herunterladen, und ein Hinweis auf der Seite sagt, wie das Repository archivierte Mail schützt. Suchen, Lesen und Herunterladen werden ins Audit-Log geschrieben.
Archiv je Mail-Job (seit 0.3.1; seit 0.4.2 als erste Frage des Editors, siehe oben).
Nur anhängbarer Speicher mit SHA-256-Hash-Kette und eine Archivprüfung (die Schaltfläche Kette prüfen oder GET /api/v1/archive/chain/verify), die zeigt, ob etwas verändert oder entfernt wurde. Sie prüft drei Dinge getrennt und nennt jedes im Ergebnis: Sie berechnet jedes Glied der Kette neu; sie gleicht die Kette mit den Tagesankern ab, die der Worker jede Nacht für jeden Mandanten versiegelt, dessen Archiv an einem abgeschlossenen Tag gewachsen ist (der Kettenwert des letzten Eintrags und die Zahl der Einträge, sodass am Ende der Kette abgeschnittene Einträge auffallen; Einträge, die neuer sind als der letzte Anker, sind noch nicht abgedeckt); und mit Kette und Stichprobe der Inhalte prüfen (der API-Parameter contentSample, 0 bis 100) liest sie bis zu 100 zufällig gewählte Nachrichten aus dem Repository zurück und vergleicht jede mit Größe und SHA-256 bei der Erfassung. Jede Prüfung wird ins Audit-Log geschrieben. Seit 0.4.4 hängen alle Schreiber über einen gemeinsamen Weg an die Kette an, und zwei Schreiber eines Mandanten können die Kette nicht mehr gabeln, indem sie Elemente mit demselben Zeitstempel versehen. Die Kette macht Manipulation erkennbar, sie verhindert sie nicht, und die Anker liegen bei Restow selbst, nicht außerhalb: siehe Archivierung und Journaling.
Aufbewahrung von 8 Jahren, die am 31. Dezember des Jahres des Eingangs plus 8 Jahre endet. In 0.4.7 ist das weiterhin ein fester Standard: Keine Oberfläche und keine API setzt eine andere Aufbewahrungsrichtlinie für das Archiv. Die Archiv-Einstellungen zeigen die geltende Frist.
Export archivierter Mail als EML-Dateien in einer ZIP-Datei (mit MANIFEST.csv und SHA256SUMS) oder als MBOX, über Mail-Dateien importieren und exportieren. Jede Anfrage und jeder Download wird ins Audit-Log geschrieben.
Nachweisbericht als JSON über die Integrations-API (GET /api/v1/archive/status und GET /api/v1/archive/report, Scope archive:read, ein Zeitraum von höchstens 366 Tagen): Elementzahlen je Erfassungsweg, die Tagesanker, die für den Mandanten gespeicherten Aufbewahrungsrichtlinien und die Legal Holds im Zeitraum. Der Kettenzustand darin steht auf not_verified, weil der Bericht die Kettenprüfung nicht ausführt. Der Vertrag bleibt bei 1.5.0 (seit 0.4.2): Weitergeleitete Kopien zählen in den Gesamtzahlen, werden aber noch nicht als eigener Weg aufgeführt. Einen PDF-Bericht und eine Oberfläche gibt es noch nicht.

Business und Service Provider

Erfassung aus den Postfächern (Fähigkeit archive.mailboxCapture): Graph-Erfassung für Microsoft 365 und IMAP-Archivierung für IMAP- und Google-Workspace-Konten, mit der einmaligen Übernahme, der Hold-Bestätigung und der Ansicht je Postfach, wie oben beschrieben. Ein Erfassungsdienst im Worker hält einen Strom je archiviertem Postfach und Weg, gleicht die Ströme alle zwei Minuten mit den Mail-Jobs ab und teilt sie unter den Worker-Prozessen auf. In der Community-Version ruht der Dienst.
Exchange-Online-Journaling: Jede journalisierte Nachricht wird erfasst, bevor ein Nutzer sie lesen, ändern oder löschen kann, über einen SMTP-Journal-Report, den Restow direkt empfängt. Die zugrunde liegende Journal-Regel lässt sich auf alle im Mandanten oder auf ausgewählte Empfänger/Gruppen beschränken. Jeder Report wird den geschützten Postfächern zugeordnet, deren Adresse sein Umschlag nennt (als Empfänger, als Absender, als Postfach, für das ein Stellvertreter gesendet hat, oder als Postfach, das weitergeleitet hat); ein Report, der kein Postfach des Mandanten nennt, wird trotzdem archiviert und gehört dann nur dem Mandanten. Journalisierte Mail ist über Betreff und Adressen durchsuchbar; der Nachrichtentext von Journal-Reports wird in 0.4.7 nicht indiziert. Journal-Reports werden in eigenen Parser-Prozessen mit Zeit- und Speichergrenze gelesen; ein Report, der sich darin nicht lesen lässt, wird trotzdem Byte für Byte archiviert, ohne seine Angaben. Die Schritte für Betreiber und Microsoft 365, das TLS-Zertifikat, das der Empfänger braucht, und der Status auf der Archiv-Seite stehen unter Exchange-Journaling.
Weitergeleitete Kopien: Derselbe Empfänger nimmt einfache Kopien an, die ein Anbieter weiterleitet (eine BCC- oder Weiterleitungsregel, ein Sieve redirect :copy, eine Routing-Regel in Google Workspace), als Erfassungsweg smtp_forward, an die Journal-Adresse des Mandanten oder an die Archivadresse eines einzelnen IMAP-Kontos.
Aufbewahrung mit durchgesetztem Löschlauf: Ein täglicher Lauf löscht nur abgelaufene Elemente ohne Legal Hold und schreibt jede Löschung samt den Hashes des Elements in das hash-verkettete Audit-Log. Ohne diese Fähigkeit wird aus dem Archiv nie etwas gelöscht.
Legal Hold: je Mandant oder je Postfach, mit Begründung, auditiert. Er setzt die Löschung für das Erfasste aus, bis er aufgehoben wird, und das Aufheben verlangt in der Oberfläche einen Grund, den das Audit-Log festhält. Ein Hold auf ein Suchergebnis ist nicht verfügbar. Ein Hold je Postfach schützt die Archivelemente, die einem Postfach zugeordnet sind: beim Import archivierte Mail sowie Journal-Reports und Erfassungen, die diesem Postfach zugeordnet sind. Reports ohne Zuordnung, dazu gehört jeder Report, der vor 0.3.1 einging, schützt nur ein mandantenweiter Hold.

Speicherziele und Unveränderbarkeit

Die Anwendung hat keinen Weg, ein archiviertes Element vor Ablauf seiner Aufbewahrung zu ändern oder zu löschen. Was das Speicherziel hinzufügt, hängt vom Ziel ab, und das Standard-Archivziel ist das lokale Volume.

Jedes Archivelement hat einen versiegelten Datensatz im Repository. Auf lokalen und NFS-Zielen erzwingt nur die Anwendung die Unveränderbarkeit des Archivs; die Oberfläche kennzeichnet solche Ziele mit „Kein Hardware-WORM“. Auf S3 mit Object Lock setzt Restow eine Object-Lock-Aufbewahrung auf die versiegelten Datensätze, bis zum Ende der Archiv-Aufbewahrung. Der Nachrichteninhalt liegt in Packs des Chunk-Stores, denselben Packs, die Backup-Daten enthalten. Seit 0.4.0 sind auch diese Packs gesperrt, wenn unveränderbare Backups für das Repository eingeschaltet sind: für den dort eingestellten Zeitraum (1 bis 3650 Tage, verlängert, solange die Packs verwendet werden), nicht für die 8 Jahre des Archivs. Ohne diese Einstellung tragen die Packs keine Sperre. Ohne Object Lock gilt der Schutz nur auf Anwendungsebene: Wer Zugriff auf die Dateien oder den Server hat, kann sie ändern oder löschen. Den archivierten Nachrichteninhalt für die ganze Archiv-Aufbewahrung zu sperren, unabhängig vom Zeitraum des Repositorys, ist geplant.

Das Feld object_lock eines Archivelements und der Zähler objectLocked in Archivstatus und Nachweisbericht bedeuten „hat ein Fristende“, nicht „liegt unter Object Lock“.

Ein erfolgreicher Test eines S3-Repositorys auf der Seite Repositories (Mandanten-Einstellungen → Repositories) zeigt, ob der Bucket Object Lock durchsetzt. Ob Backup-Daten und archivierte Inhalte gesperrt werden, stellen Sie auf der Karte des Repositorys unter Unveränderbare Backups ein. Was das praktisch heißt, steht unter Archivierung und Journaling, und ob die GoBD tatsächlich speziell WORM verlangen, unter Vorschriften.

Bekannte Probleme

Das sind die bekannten Probleme der Erfassungswege seit 0.4.4:

Gegen Simulationen getestet, nicht gegen echte Dienste. Die Graph-Erfassung wurde gegen eine simulierte Graph-API getestet, die IMAP-Archivierung gegen einen simulierten IMAP-Server und den Dovecot des Release-Smokes, die Weiterleitung gegen den Empfänger selbst; nie gegen einen echten Microsoft-365- oder Google-Workspace-Mandanten, Postfix, mailcow oder Hoster. Probieren Sie jeden Weg mit einem Testpostfach aus, bevor Sie sich darauf verlassen.
Holds in einem Microsoft-365-Mandanten werden nicht erkannt. Graph v1.0 bietet keinen Weg, sie zu lesen, deshalb bestätigt eine Administration sie je Quelle. 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 fehlen. Graph kann Mail über etwa 150 MB nicht exportieren; solche Mail wird protokolliert, nicht archiviert.
Der Journal-Empfänger prüft den Absender nicht (SPF), und seine Grenzen zählen je api-Prozess.
IMAP-Quellen mit OAuth2 lassen sich noch nicht anlegen, weder in der API noch in der Oberfläche; ein Google-Workspace-Konto wird deshalb nur an seinem Host (imap.gmail.com, imap.googlemail.com) oder seiner Ordnerliste erkannt.
Worauf die IMAP-Erfassung verzichtet, steht nur im Log des Workers (seit 0.4.7): eine Nachricht, auf die sie nach drei Durchläufen verzichtet hat, und Nachrichten, die der Backfill nicht lesen konnte.
Die Integrations-API führt weitergeleitete Kopien nur in den Gesamtzahlen auf, nicht als eigenen Weg (Vertrag 1.5.0, siehe Integrations-API).

In Entwicklung

Auf dieser Seite ist nichts in Entwicklung, was nicht unter Geplant steht, und das trägt keine Versionsnummer. Die Punkte, die hier früher standen (Graph-Erfassung, Weiterleitung, IMAP-Archivierung, der Job-Editor, der die Art der Quelle erkennt, fertige Journaling-Befehle und das Zusammenführen derselben Mail), sind seit 0.4.4 verfügbar und oben beschrieben. Die übrigen Punkte (Self-Service-Suche, rollenbezogene Suche, Prüfer-Export, signierter PDF-Nachweisbericht, Wahl je Postfach und Generator für die Verfahrensdokumentation) sind geplant und nicht in 0.4.7.

Geplant

Beschlossen, nicht begonnen, ohne Termin. Die Roadmap nennt, was als Nächstes und was später kommt.

Nachweis und Speicherung

Tägliche externe Anker für die Archiv-Kette (per E-Mail an den Betreiber, optional ein RFC-3161-Zeitstempel). Der Worker versiegelt jede Nacht einen Tagesanker der Kette, und die Archivprüfung gleicht sich damit ab, aber die Anker bleiben innerhalb von Restow: Nichts verschickt sie oder versieht sie extern mit einem Zeitstempel.
Object Lock für archivierte Nachrichteninhalte, das der Aufbewahrung des Archivs folgt, in eigenen Packs, statt dem Sperrzeitraum des Repositorys. Backups haben seit 0.4.0 ein rollierendes Sperrfenster (siehe Unveränderbare Backups).
Ein Hintergrundlauf der Archivprüfung mit Fortschritt. Heute läuft sie in einer Anfrage.
Eine Prüfung des Absenders von Journal-Reports und weitergeleiteten Kopien (SPF, Microsoft-Adressbereiche).

Aufbewahrung

Eine Aufbewahrungsrichtlinie je Mandant (6, 8, 10 Jahre oder unbegrenzt), optional je Postfach-Gruppe, mit Fristbeginn zum Erfassungsdatum oder zum Ende des Kalenderjahres.
Ein Löschprotokoll (Anzahl, Zeitraum, Hashes der gelöschten Objekte) als eigener Eintrag der Kette.
Ein Legal Hold auf ein Suchergebnis.

Suche, Export und Nachweis

Suche in Anhängen (PDF, DOCX, XLSX, TXT) und nach Größe.
Self-Service-Archivsuche für Endnutzer: die eigene Mail-Historie durchsuchen und Treffer nicht-destruktiv wiederherstellen oder herunterladen (siehe Nutzung).
Rollenbezogene Archivsuche mit Vier-Augen-Freigabe, bevor eine Provider-Administration im Archiv eines Kunden suchen kann.
Prüfer-Export und signierter Nachweisbericht: ein Export als EML/ZIP, der auch die Kettenwerte enthält (CHAIN.txt), sowie ein signierter PDF-Nachweisbericht je Mandant. Ein einfacher Export mit Manifest und Prüfsummen und der Nachweisbericht als JSON sind bereits verfügbar (siehe oben).
Weitergeleitete Kopien als eigener Weg im Archivstatus und im Nachweisbericht der Integrations-API.
Wahl je Postfach, ob nur gesichert oder gesichert und archiviert wird, über denselben Regelmechanismus wie beim Backup-Umfang, mit getrennten Spalten Backup und Archiv auf dem Reiter Schutz (Mandanten-Einstellungen → Schutz). Siehe Archivierung und Journaling.

Verfahren

Generator für die Verfahrensdokumentation: ein Dokument je Mandant, aus der tatsächlichen Konfiguration und einer Vorlage erzeugt, als Markdown und PDF, versioniert und mit Datum. Das vollständige Dokument bleibt die eigene Verantwortung Ihrer Organisation.

Was Restow nicht behauptet

Keine Zertifizierung. Restow ist für den GoBD-konformen Einsatz ausgelegt, mit Nennung der konkreten Maßnahmen. IDW PS 880 ist ein Prüfungsstandard für Software, teuer und optional, und keine Software kann ein Zertifikat ausstellen, das die Finanzverwaltung bindet. Ob der Einsatz für Ihre Organisation ausreicht, bestätigt am Ende Ihre Steuerberatung.
Kein Ersatz für die Prüfung durch Steuerberatung oder Datenschutzbeauftragte.
Kein Anspruch auf Vollständigkeit über das hinaus, was das Archiv erreicht hat: Mail, die weder erfasst noch importiert wurde, ist nicht darin. Für zeitnah erfasste Mail (Graph, IMAP-Archivierung) gibt es keine Garantie der Vollständigkeit; sie wird als solche gekennzeichnet.
Keine Hardware-WORM-Garantie ohne Object Lock: Auf lokalem Speicher und NFS gilt die Unveränderbarkeit nur auf Anwendungsebene.
Kein Anspruch, dass unveränderbare Backups die GoBD erfüllen. Sie schützen Backup-Daten vor dem Löschen vor einem Datum, das ist eine technische Maßnahme, kein rechtlicher Schluss.