← Alle Funktionen

Mail-Import und -Export

Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am 2026-10-29

Restow liest Mail-Dateien ein, etwa die Reste eines Postfachs, das es nicht mehr gibt, das aber aufbewahrt werden muss, und macht daraus ein Altpostfach, das Sie durchsuchen und wiederherstellen können. Mails gibt Restow außerdem als Dateien wieder aus: aus Backups, aus importierten Postfächern und aus dem Archiv. Die Funktion ist in jeder Edition verfügbar, seit 0.1.0, und nennt, was sie nicht kann, direkt neben dem, was sie kann. Dieselbe Seite behandelt das Archiv, in das importierte Mail optional aufgenommen wird, die Wege, auf denen Mail aus den Postfächern selbst hineinkommt (Business und Service Provider, seit 0.4.4), und die darauf aufbauende, für den GoBD-konformen Einsatz ausgelegte Schicht.

Was sich importieren lässt

• EML: einzelne Dateien, Ordner oder eine ZIP-Datei.
• MSG (Outlook): einzelne Dateien, Ordner oder eine ZIP-Datei. Nur Mail-Nachrichten; Termine, Kontakte und Aufgaben in MSG-Form werden als „keine Mail“ gemeldet und nicht importiert.
• MBOX: Thunderbird (auch die .sbd-Ordner), Apple Mail, Exporte von Dovecot und Postfix sowie Google Takeout.
• ZIP: Die Ordnerstruktur im Archiv wird zur Ordnerstruktur des Postfachs, mit EML, MSG und MBOX darin.
• MailStore: ein Export als EML- oder MSG-Ordnerbaum oder eine ZIP-Datei davon. Das interne Archivformat von MailStore kann Restow nicht lesen; exportieren Sie in MailStore die Mails ins Dateisystem als EML oder MSG.

Wie die Dateien hereinkommen

Sie können Dateien im Browser hochladen. Der Upload läuft in Stücken und ist wiederaufnehmbar, standardmäßig bis 10 GiB je Datei, und jedes Stück trägt eine SHA-256-Prüfsumme. Jedes Stück wird mit dem Mandantenschlüssel versiegelt, sobald es ankommt, vom ersten Byte an, und auf Ihrem Speicherziel abgelegt, sodass keine Klartextkopie der Datei auf eine Platte geschrieben wird. Der Dateityp wird am Inhalt erkannt, nie an der Endung.

Die Alternative ist ein Import-Ordner auf dem Server, schreibgeschützt eingehängt, mit einem eigenen Unterordner je Mandant. Der Administrator legt dort Dateien oder ganze Ordnerbäume ab, zum Beispiel einen MailStore-Export, und wählt sie in der Oberfläche aus. Restow schreibt nie in diesen Ordner und leert ihn nie, und es prüft, dass jeder Pfad innerhalb des eigenen Unterordners des Mandanten bleibt.

Was Sie bekommen

Ein Import legt eine eigene Quelle an (Imported mail files) mit einem Altpostfach, das die Ordnerstruktur behält. Es erscheint im Restore-Explorer wie jedes andere Postfach, als importiert gekennzeichnet. Sie können es durchsuchen, Nachrichten in der Vorschau ansehen und drucken, herunterladen und in ein bestehendes IMAP-Konto oder ein Microsoft-365-Postfach wiederherstellen (unter einem neuen Wiederherstellungsordner; vorhandene Elemente werden nie ersetzt). „Ins Original zurückspielen“ gibt es nicht, weil es kein Original gibt. Jeder Import fügt einen neuen Snapshot hinzu, der alles Bisherige plus die neuen Mails enthält, sodass sich ein Altpostfach aus mehreren Dateien nacheinander aufbauen lässt.

• EML und MBOX werden byte-genau gespeichert. Eine MSG-Datei enthält keine fertige E-Mail, daher rekonstruiert Restow daraus eine EML aus den gespeicherten Eigenschaften (Kopfzeilen, wenn Outlook sie mitgespeichert hat, Text, HTML, Anhänge, eingebettete Nachrichten). Der Bericht zählt diese Nachrichten als aus MSG rekonstruiert.
• Eine Nachricht mit derselben Message-ID und demselben SHA-256 im selben Ordner ist ein Duplikat: Sie wird nicht noch einmal gespeichert, aber gezählt und aufgelistet. Dieselbe Datei zweimal zu importieren ergibt „nichts Neues“ und keinen Snapshot.
• Jedes unlesbare oder beschädigte Element steht mit seinem Grund im Importbericht, und Harmloses wie leere Dateien steht als übersprungen darin. Nichts fällt stillschweigend weg.
• Startet der Import-Worker neu, macht er dort weiter, wo er stehen geblieben ist, und liest nie eine Nachricht doppelt.

Optional nehmen Sie die importierten Mails ins Archiv auf (die Option, gleichzeitig zu archivieren, in jeder Edition verfügbar): Jede neue Nachricht wird ein Archivobjekt mit den Original-Bytes, Hash-Kette, den Aufbewahrungseinstellungen des Archivs und einer Suche über Betreff, Adressen und Nachrichtentext (Anhangsinhalte werden nicht durchsucht). Die Aufbewahrungsfrist beginnt mit dem Importdatum, nicht mit dem Datum der Nachricht, und das Archiv ist ab der Aufnahme nur anhängend und manipulationserkennbar (Hash-Kette). Was eine Änderung verhindert, ist eine Frage des Repositorys: siehe „Unveränderbarkeit und das Archiv“ unten.

Das Archiv

Das Archiv ist ein nur anhängbarer Speicher für Mail mit einer SHA-256-Hash-Kette, in jeder Edition. Mail kommt durch den Mail-Import mit Archivierung hinein, wie oben beschrieben, und in Business und Service Provider aus den Postfächern selbst (siehe „So kommt Mail ins Archiv“ unten). Das Archiv schalten Sie je Mail-Job ein. Die Suche umfasst Betreff, Adressen und den Nachrichtentext (keine Anhänge), blättert durch ihre Ergebnisse und filtert nach Absender, Datum und Postfach. Jeder Treffer nennt den Weg, der die Mail erfasst hat, und eine Mail, die mehrere Wege erfasst haben, zeigt sie alle.

• Die Kettenprüfung verifiziert jedes Glied der Hash-Kette, die täglichen Anker (jede Nacht geschrieben) und auf Wunsch eine Stichprobe der Nachrichteninhalte.
• Archivierte Nachrichten lassen sich in Restow lesen und als .eml herunterladen.
• Ein Hinweis sagt, wie der Speicher archivierte Mail schützt.
• Das Archiv lässt sich wie ein Postfach exportieren, siehe unten. Der Export einer Suche lässt die Erfassungen weg, die ein stärkerer Weg ersetzt hat, wie die Suche selbst.

So kommt Mail ins Archiv

Seit 0.4.4 hat das Archiv mehr Wege hinein als das Journaling. Der Mail-Job-Editor fragt „So gelangen E-Mails ins Archiv“ und bietet je Art von Postfach im Job nur die Wege an, die dazu passen (Microsoft 365, IMAP, Google Workspace über IMAP; für IMAP-Konten bei einem Microsoft-Host schlägt er vor, stattdessen eine Microsoft-365-Quelle zu verbinden). Jeder Weg ist als „Echt“ (beim Transport) oder „Zeitnah“ gekennzeichnet, je Art ist mindestens einer nötig, und Wege lassen sich kombinieren. Vorgabe eines neuen Jobs sind Graph für Microsoft 365 und IMAP-Abgleich für IMAP und Google Workspace. All das gehört zu Business und Service Provider; der Community-Build lässt die Erfassung ruhen.

• Microsoft Graph (Microsoft 365, zeitnah). Restow abonniert für jedes archivierte Postfach Änderungsbenachrichtigungen von Graph und holt jede neue Mail binnen Minuten nach der Zustellung. Es braucht keine neue Microsoft-Berechtigung, keinen Port 25 und keine Journalregel. Graph meldet neue Mail nur, wenn die öffentliche URL der Installation https auf Port 443 ist und von Microsoft erreichbar; sonst fragt Restow jedes Postfach ab, standardmäßig alle 15 Minuten, und die Archiv-Seite nennt den Grund.
• Exchange-Journaling (Microsoft 365, echt). Exchange Online schickt einen Journalbericht jeder Mail, solange sie im Transport ist; die Kopie existiert also, bevor ein Nutzer die Mail anfassen kann, einschließlich BCC-Empfängern und sofort gelöschter Mail. Das bleibt der stärkste Nachweis. Es braucht den Journal-Empfänger mit einem eigenen TLS-Zertifikat und Port 25. Die Archiv-Seite erzeugt jetzt die Befehle für Exchange Online PowerShell (Connector, Postfach für nicht zustellbare Journalberichte, Journalregel) zum Kopieren und wartet auf den ersten Report.
• IMAP-Abgleich mit IDLE (IMAP und Google Workspace, zeitnah). Restow gleicht das Konto laufend ab und archiviert jede neue Mail, sobald sie im Postfach liegt: mit IMAP IDLE, wo der Server es anbietet (eine offene Verbindung je Konto), sonst durch Prüfungen in Abständen, auf die sich eine Quelle für Anbieter mit knappem Verbindungslimit auch einstellen lässt. Gelesen werden alle Ordner außer Entwürfen; bei Gmail und Google Workspace nur Alle Nachrichten, Spam und Papierkorb, die jede Mail genau einmal enthalten. Seit 0.4.7 hält eine Nachricht, die der Server ablehnt oder nicht ausliefert, ihren Ordner oder den ganzen Durchlauf nicht mehr auf (die Erfassung gibt sie nach drei Durchläufen auf und nennt sie nur im Worker-Log), Ordner, die ein Durchlauf nicht erreichte, behalten ihren Stand, und eine Beobachtung, die der Server mit einem NO auf EXAMINE oder IDLE ablehnt, wird nach Minuten wiederholt, statt den Server einen Tag lang für einen ohne IDLE zu halten.
• Weitergeleitete Kopien (IMAP und Google Workspace, echt). Der Mailanbieter schickt eine Kopie jeder ein- und ausgehenden Mail an Restow, solange die Mail in seinem Transport ist: eine BCC-Regel in Postfix oder mailcow, eine Sieve-Regel oder die Routing-Regel „Weitere Empfänger hinzufügen“ in Google Workspace. Jedes IMAP-Konto kann eine eigene Archivadresse haben, sodass die Kopie genau diesem Konto zugeordnet wird; eine Kopie an die Journal-Adresse des Mandanten wird nach ihren Kopfzeilen zugeordnet. Die Archiv-Seite zeigt, wie die Regel einzurichten ist und ob Kopien ankommen. Eine solche Kopie hat keinen Journal-Umschlag: BCC-Empfänger sind nur sichtbar, wenn der Anbieter sie in eine Kopfzeile schreibt, und eine Sieve-Kopie deckt nur eingehende Mail ab.
• Mail-Import mit Archivierung (jede Edition, nachträglich). Wie oben beschrieben; die Aufbewahrungsfrist beginnt mit dem Importdatum.

Graph, IMAP-Abgleich und weitergeleitete Kopien übernehmen die Mail, die schon im Postfach liegt, jeweils einmalig in fortsetzbaren Schritten und markieren sie als „Nachträglich erfasst“. Mail, die über mehr als einen Weg ins Archiv gelangt, wird an Message-ID und Inhalt erkannt und einmal aufbewahrt: Eine Erfassung, die nicht stärker ist als das, was das Archiv hält, wird ein Erfassungseintrag an diesem Element, und eine stärkere (etwa eine weitergeleitete Kopie nach einem IMAP-Abgleich) wird das Element und nennt die frühere Erfassung, die sie ersetzt und die in der Kette unverändert bleibt. Journalberichte und importierte Nachrichten bleiben eigene Elemente. Kommt dieselbe Message-ID mit anderem Body, bleiben beide erhalten und werden markiert.

Die Archiv-Seite zeigt den Erfassungsstatus (Streams, wie neue Mail bemerkt wird, Zahlen der letzten 24 Stunden und 7 Tage, die Übernahme des Altbestands), die Erfassung je Postfach mit einem Nachholen auf Wunsch, die Weiterleitungsadressen und die Befehle für das Exchange-Journaling, und Warnungen melden, wenn eine Erfassung stockt: ein Postfach länger als eine Stunde im Fehler, weitergeleitete Kopien, die seit 24 Stunden ausbleiben, oder eine Journal-Adresse ohne Reports seit 24 Stunden.

Seit 0.4.7 gehört das Archiv zum empfohlenen Job. Solange die Installation die Erfassung aus dem Postfach anbietet (Business und Service Provider) und der Mandant Postfächer oder Konten hat, die ein Archiv erfassen kann, lassen „Empfohlenen Job anlegen“ und „Alles ohne Job schützen“ den neuen Mail-Job über alle Objekte sichern und archivieren. Ein bestehender Mail-Job über alle Objekte, der noch nicht archiviert, wird stattdessen auf Archivierung umgeschaltet („Archivierung einschalten in ...“): Seine Zeitpläne bleiben, die Änderung wird wie eine Bearbeitung im Job-Editor im Audit-Log festgehalten, und sie geschieht nur, wenn ein Administrator die Empfehlung anwendet. Der Klick nimmt die Vorgabe-Erfassungswege, die im Mandanten nichts weiter brauchen, Microsoft Graph für Microsoft-365-Postfächer und IMAP-Abgleich für die übrigen Konten; Journaling und Weiterleitung bleiben eine Wahl im Editor. Ein Mail-Job über ausgewählte Objekte wird nie geändert, und ein Mail-Job über alle Objekte, dessen Erfassungswege von Hand gewählt wurden, bleibt, wie er ist. Die Liste der Mail-Jobs zeigt „Archivierung einschalten“, wo die Empfehlung sie einschalten würde. Ohne die Erfassung entsteht der empfohlene Job wie bisher.

Was zeitnahe Erfassung nicht verspricht

• Graph und IMAP-Abgleich holen eine Mail kurz nach der Zustellung aus dem Postfach, nicht beim Transport. Eine Mail, die in dieser Lücke verschoben oder gelöscht wird, kann fehlen. In Microsoft 365 schließt eine Aufbewahrungsrichtlinie oder ein Litigation Hold, der gelöschte Mail aufbewahrt, die Lücke für gelöschte Mail. Restow kann solche Holds nicht sehen (Graph bietet keinen Lesezugriff darauf); ein Administrator bestätigt den Hold deshalb je Quelle, und die Archiv-Seite zeigt die lesenden Befehle für Exchange Online PowerShell, die ihn prüfen. IMAP hat nichts Vergleichbares.
• Von den wiederherstellbaren Elementen wird nur der Ordner der Löschungen gelesen; Mail, die endgültig gelöscht wurde, bevor Restow sie holte, kann fehlen. Graph kann Mail über etwa 150 MB nicht exportieren; solche Mail wird protokolliert, nicht archiviert. Restow sieht BCC-Empfänger nur beim Absender, und Mail, die eine Anwendung ohne Kopie in „Gesendete Elemente“ verschickt, fehlt.
• Journaling und weitergeleitete Kopien zeigen eine Mail so, wie sie durch den Server ging; die zeitnahe Erfassung zeigt sie so, wie sie kurz danach im Postfach lag. Restow kennzeichnet jede Erfassung und behauptet für die zeitnahen Wege keine Vollständigkeit.
• Gegen eine simulierte Microsoft-Graph-API, einen simulierten IMAP-Server, den Dovecot des Release-Smoke-Laufs und den Empfänger selbst getestet, nie gegen einen echten Microsoft-365- oder Google-Workspace-Mandanten, Postfix, mailcow oder Hoster. Der Empfänger prüft den Absender nicht (SPF). IMAP-Quellen mit OAuth2 lassen sich noch nicht anlegen; ein Google-Workspace-Konto wird deshalb an seinem Host oder seiner Ordnerliste erkannt.
• Mail-Jobs, die schon vor 0.4.4 archiviert haben, behalten genau das, was sie taten: nur Journaling für Microsoft 365 und noch keinen Weg für IMAP- und Google-Workspace-Konten, sodass nichts Neues von selbst startet. Ein Administrator schaltet Graph oder die IMAP-Archivierung im Job ein.

Unveränderbarkeit und das Archiv

Die Hash-Kette macht eine Änderung sichtbar, sie verhindert sie nicht. Was sie verhindert, ist der Speicher, und das ist eine Einstellung des Repositorys. Die Datensätze der Archivelemente behalten ihre eigene Aufbewahrung, wie bisher. Der Nachrichteninhalt liegt im selben Chunk-Store wie Backups, daher sperrt seit 0.4.0 die Einstellung für Unveränderbarkeit eines Repositorys auf S3 mit Object Lock (Compliance- oder Governance-Modus, 1 bis 3650 Tage) auch die Packs, die ihn halten. Ein lokales oder NFS-Repository bekommt nur eine Löschverzögerung, die Restow selbst erzwingt: Wer Zugriff auf den Server oder die Freigabe hat, kann die Dateien trotzdem löschen, und die Oberfläche beschriftet sie mit „Löschverzögerung (nicht unveränderbar)“. Das Standard-Repository der Installation lässt sich nicht unveränderbar machen; geben Sie dem Mandanten ein eigenes Repository. Einzelheiten, was nicht gesperrt ist und wovor es nicht schützt, stehen auf der Speicherseite. Es wurde gegen ein simuliertes S3 getestet, noch nicht gegen einen echten S3-Dienst mit Object Lock.

Die GoBD-Schicht, ab Business

Business und Service Provider ergänzen das Archiv um eine für den GoBD-konformen Einsatz ausgelegte Schicht:

• Erfassung aus den Postfächern per Graph und IMAP-Abgleich sowie Erfassung beim Transport durch den Empfang von Journalberichten aus Exchange Online per SMTP und durch Kopien, die ein Mailanbieter weiterleitet (der Empfänger braucht ein eigenes TLS-Zertifikat). Jeder Journalbericht wird den Postfächern zugeordnet, die er nennt.
• Aufbewahrungsrichtlinien mit einem durchgesetzten Löschlauf.
• Legal Hold je Mandant oder je Postfach. Ein Hold wird mit einer verpflichtenden Begründung aufgehoben, und die Aufhebung wird protokolliert.

Es gelten dieselben Grenzen wie oben: Was eine Änderung verhindert, ist das Repository, nicht die Schicht. Hintergrund steht unter E-Mail-Archivierung nach GoBD.

Export

Sie können Postfächer oder Ordner aus Backups (Microsoft-365-Postfächer und IMAP-Konten), importierte Postfächer und das Archiv exportieren, in einem von zwei Formaten:

• EML in einer ZIP-Datei: eine .eml je Nachricht mit der Ordnerstruktur, dazu MANIFEST.csv und SHA256SUMS (prüfbar mit sha256sum -c). Die Bytes sind die gespeicherten Originale.
• MBOX: Ein einzelner Ordner wird eine .mbox-Datei, mehrere Ordner werden eine ZIP-Datei mit einer .mbox je Ordner, dazu Manifest und Prüfsummen.

Die Exportdatei wird verschlüsselt auf Ihr Speicherziel geschrieben, und beim Schreiben wird der SHA-256 jeder Nachricht gegen das Manifest geprüft, sodass ein beschädigter Chunk den Export abbricht, statt eine still fehlerhafte Datei zu liefern. Der Download-Link gilt 24 Stunden. Die Anforderung und jeder Download stehen im Audit-Log, und bei Exporten fremder Daten wird eine Begründung festgehalten. Exportiert wird nur Mail: Kalendereinträge und Kontakte werden im Bericht gezählt, nicht exportiert.

Benannte Grenzen, nicht versteckte

• PST- und OST-Dateien werden erkannt und mit einer Erklärung abgelehnt. PST-Import, PST-Export und MSG-Export sind geplant, siehe die Roadmap. EML in einer ZIP-Datei enthält dieselben Nachrichten in der Originalform.
• Termine und Kontakte in MSG-Dateien werden nicht importiert, und das interne Archivformat von MailStore lässt sich nicht lesen.
• Aus MSG wird ein Körper, der nur als RTF vorliegt, nicht dekodiert (Restow nimmt dann den Text-Körper), und Anhänge, die nur auf eine Datei verweisen, entfallen. Andere Archivarten (gz, 7z, rar, tar) und Apple-.emlx-Dateien werden erkannt und als nicht unterstützt gemeldet, und passwortgeschützte oder verschachtelte ZIP-Dateien werden gemeldet und nicht geöffnet.
• Mail-Dateien werden in eigenen Hilfsprozessen mit Speicher- und Zeitgrenzen gelesen, nie im Serverprozess selbst. Eine Nachricht, die sich darin nicht lesen lässt, wird als unlesbar gemeldet (oder Byte für Byte ohne Betreff, Absender und Text importiert), und der Import läuft weiter. Uploads, deren Import noch aussteht, dürfen standardmäßig bis zu 100 GiB je Mandant belegen, noch nicht abgelaufene Exportdateien bis zu 50 GiB je Mandant; beide Grenzen lassen sich ändern.
• Ein importiertes Postfach lässt sich noch nicht löschen, und die Import-Quelle ebenso wenig, solange sie Snapshots, Archivobjekte oder Legal Holds hält.
• Die Aufbewahrungsfrist des Archivs für aufgenommene Mails beginnt mit dem Importdatum.

Dokumentation

Das Administrator-Handbuch beschreibt die Schritte unter Mail-Import und -Export. Für Mails, die aus einem importierten Postfach wiederhergestellt werden, gelten die Regeln der Restore-Seite.

Häufig gefragt

Weiter zu: Wie Restore funktioniert →

Mehr in Wissen: das Backup-Glossar (Archiv, Hash-Kette, Journaling, Legal Hold) →

Mehr in Wissen: Backup und Archivierung, und warum das eine das andere nicht ersetzt →