Mail-Dateien importieren und exportieren

Manche Mail muss aufbewahrt werden, obwohl das Postfach, aus dem sie stammt, nicht mehr existiert: ein ehemaliger Mitarbeiter, eine aufgegebene Domain, ein alter Mailserver. Der Import übernimmt solche Mail aus Dateien in Restow, wo sie sich wie jede Sicherung durchsuchen, ansehen und wiederherstellen lässt. Der Export geht den umgekehrten Weg: Er schreibt Mail, die Restow hält, als Dateien heraus, die Sie weitergeben oder in einem anderen Programm öffnen können.

Was sich importieren lässt

Quelle	Was gelesen wird
EML	Einzelne Dateien, Ordner mit Dateien oder ein ZIP davon.
MSG (Outlook)	Einzelne Dateien, Ordner oder ein ZIP. Nur Mail-Nachrichten: Kontakte, Termine und Aufgaben in MSG-Form werden als „keine Mail“ gemeldet und nicht importiert.
MBOX	Thunderbird (auch `.sbd`-Ordner), Apple Mail (`X.mbox/mbox`), Dovecot- und Postfix-Exporte, Google Takeout. Zeilenenden CRLF und LF funktionieren, die mboxrd-Maskierung wird zurückgenommen.
ZIP	Die Ordnerstruktur im ZIP wird zur Ordnerstruktur des Postfachs. Darin dürfen EML-, MSG- und MBOX-Dateien liegen.
MailStore	Ein Export als EML- oder MSG-Ordnerbaum (der Ordner oder ein ZIP davon).

Restow erkennt, was eine Datei ist, am Inhalt (die ersten 64 KiB), nie an der Endung. Importiert wird nur Mail.

Das interne Archivformat von MailStore kann Restow nicht lesen. Wählen Sie in MailStore „E-Mails exportieren“ ins Dateisystem (EML oder MSG) und importieren Sie dann diesen Ordner oder ein ZIP davon.

Was nicht unterstützt wird

PST- und OST-Dateien. Sie werden am Inhalt erkannt und mit einer klaren Meldung abgelehnt, nie geparst. Der Import von PST und OST ist für eine spätere Version geplant. Exportieren Sie das Postfach bis dahin aus Outlook als MSG- oder EML-Dateien (Nachrichten in einen Ordner ziehen) oder wandeln Sie es mit einem Konverter nach MBOX und importieren Sie das Ergebnis.
PST-Export und MSG-Export. Beide sind geplant. Es gibt noch keinen MSG-Schreiber mit geklärter, tragbarer Lizenz, deshalb bietet der Export-Dialog kein MSG an, und PST ist als geplant gekennzeichnet. Ein EML-Export enthält dieselben Nachrichten in der Originalform: Outlook öffnet EML-Dateien per Drag and Drop, und MBOX lässt sich mit gängigen Werkzeugen importieren.
Kalender und Kontakte. Importiert und exportiert wird nur Mail.
Andere Container. gz, 7z, rar, tar und Apple-.emlx-Dateien werden erkannt und als nicht unterstützt gemeldet, aber nicht geöffnet. Reste von Betriebssystemen (.DS_Store, Thumbs.db, desktop.ini, __MACOSX, Thunderbird-.msf) stehen als „keine Mail“ im Bericht, nie als Fehler.

Was ein Import erzeugt

Ein Import legt ein importiertes Postfach an oder erweitert es. Es liegt unter einer Quelle je Mandant mit dem Namen Importierte Mail-Dateien, die weder Server noch Zugangsdaten hat: Von dort wird nie etwas gesichert, es gibt also keine Verbindung einzurichten oder zu testen. Das Postfach taucht in keinem Backup-Zeitplan auf und erscheint nie als ungeschützt oder überfällig.

Dasselbe Format wie ein IMAP-Backup. Jede Nachricht wird als eigene EML im verschlüsselten Chunk-Store abgelegt, mit erhaltener Ordnerstruktur. Deshalb funktionieren Restore-Explorer, Vorschau, Druckansicht, Download und IMAP-Restore für importierte Mail ohne Sonderwege, und das Postfach trägt dort das Kennzeichen „Importiert“.
Byte-genau, außer bei MSG. EML und MBOX werden genau so gespeichert, wie sie in der Datei stehen. Eine MSG-Datei enthält keine RFC-5322-Nachricht, daher rekonstruiert Restow aus den gespeicherten Eigenschaften eine EML: Kopfzeilen (wenn Outlook sie mitgespeichert hat), Text, HTML, Anhänge und eingebettete Nachrichten. Der Bericht zählt diese Nachrichten als „aus MSG neu aufgebaut“.
Jeder Import fügt einen Snapshot hinzu. Ein neuer Snapshot enthält alles aus dem vorigen plus die neuen Nachrichten. Nichts wird entfernt, sodass Sie ein Altpostfach aus mehreren Dateien nacheinander aufbauen können.

Ordner

Eine einzelne a.eml oder a.msg ohne Verzeichnis landet im Ordner Imported.
Verzeichnisse werden zu Ordnern (dir/sub/a.eml nach dir/sub). Leere Verzeichnisse bleiben als leere Ordner erhalten.
Eine MBOX-Datei x.mbox oder eine Datei Inbox ohne Endung (erkannt am Inhalt) wird zum Ordner x bzw. Inbox. Thunderbird-Verzeichnisse Inbox.sbd/ werden zu Unterordnern von Inbox. Apple Mail X.mbox/mbox wird zu X.
In einem ZIP geben die Pfade die Ordner vor. Einträge ohne Verzeichnis kommen in einen Ordner mit dem Namen der ZIP-Datei.

Die Dateien hineinbringen

Öffnen Sie Mandanten-Einstellungen → Verbindungen → Quelle hinzufügen → Mail-Dateien importieren oder Mail-Dateien importieren auf dem Reiter Importe daneben. Es gibt zwei Wege.

Upload im Browser

Stückweise und wiederaufnehmbar. Die Datei wird in Stücken gesendet (standardmäßig 8 MiB), drei gleichzeitig, jedes mit eigener SHA-256-Prüfsumme. Bricht das Netz ab oder wird der Tab geschlossen, gehen nur die gerade laufenden Stücke verloren. Wählen Sie dieselbe Datei erneut (erkannt an Name und Größe), werden nur die fehlenden Stücke gesendet.
Ab dem ersten Byte versiegelt. Jedes Stück wird in dem Moment, in dem es ankommt, mit dem Mandantenschlüssel verschlüsselt (AES-256-GCM) und als eigenes Objekt im primären Speicherziel des Mandanten abgelegt. Der Worker liest die Datei später aus diesen Stücken. Es entsteht keine Klartextkopie der Datei auf einer Platte, und nie liegt eine ganze Datei im Speicher, höchstens ein Stück oder eine einzelne Nachricht.
Grenzen. IMPORT_MAX_FILE_BYTES (standardmäßig 10 GiB je Datei), höchstens 20 offene Uploads je Mandant, und ein unfertiger oder ungenutzter Upload verfällt nach 48 Stunden (IMPORT_UPLOAD_TTL_HOURS). Abbrechen löscht die Stücke sofort. Ordner lassen sich nicht hochladen: Packen Sie einen Ordner vorher in ein ZIP.
Staging-Budget. Die Uploads eines Mandanten, deren Stücke noch liegen (offene Uploads und die Dateien eines Imports, der noch nicht beendet ist), dürfen zusammen höchstens IMPORT_MAX_STAGING_BYTES ankündigen, standardmäßig 100 GiB. Ein neuer Upload, der nicht mehr hineinpasst, wird abgewiesen, bevor sein erstes Stück gesendet wird (import-staging-full), und der Dialog sagt, was zu tun ist: warten, bis ein Import abgeschlossen ist, einen Upload entfernen oder große Dateien in den Import-Ordner auf dem Server legen, der kein Staging belegt.
Aufräumen. Die Stücke werden direkt nach dem Import, beim Abbruch und bei Ablauf entfernt. Der Retention-Lauf räumt Reste ab: abgelaufene und abgebrochene Uploads, die Dateien eines Imports, der endgültig beendet ist, Staging-Ordner, die kein Upload mehr kennt, und nach 48 Stunden Uploads, deren Import-Job verschwunden ist. Solange ein Import noch wiederholt werden kann, bleiben seine Dateien im Staging.

Import-Ordner auf dem Server

Für sehr große Archive, die Sie nicht durch den Browser senden möchten, legen Sie die Dateien auf dem Restow-Server ab.

RESTOW_IMPORT_DIR ist ein Verzeichnis auf dem Host. Der Release-Stack bindet es schreibgeschützt unter /var/lib/restow/import in den Containern api und worker ein.
Jeder Mandant hat darin seinen eigenen Unterordner, <RESTOW_IMPORT_DIR>/<Mandanten-Slug>/, auch eine Installation mit nur einem Mandanten. Der Slug steht in den Mandanteneinstellungen, der Import-Assistent zeigt den vollständigen Pfad an. Den Unterordner legen Sie selbst an, und das Verzeichnis muss für den Benutzer lesbar sein, als der die Container laufen.
Legen Sie dort Dateien oder ganze Ordnerbäume ab (zum Beispiel einen MailStore-Export) und wählen Sie sie in der Oberfläche aus.
Restow beschreibt diesen Ordner nie und leert ihn nie. Pfade werden gegen Ausbrüche geprüft (.., Symlinks nach außen, Sonderdateien), und sowohl die API als auch der Worker prüfen, dass ein Pfad unterhalb des eigenen Unterordners des Mandanten liegt. So kann ein Mandant nichts sehen oder importieren, was ein anderer dort abgelegt hat.

Der Import-Job

Wählen Sie Quelle, Dateien und Ziel (ein neues importiertes Postfach mit einem Namen oder ein vorhandenes) und starten Sie den Import mit Import starten. Der Import läuft im Hintergrund, Sie können die Seite verlassen und ihn auf dem Reiter Importe (Mandanten-Einstellungen → Verbindungen) verfolgen.

Fortschritt. Gelesene Bytes von der Gesamtgröße (mit Prozent und Restzeit), Zähler für Nachrichten, Duplikate, übersprungene und fehlgeschlagene Elemente sowie die aktuelle Phase.
Checkpoints. Nach jeder fertigen Datei und alle 500 Nachrichten (oder 256 MiB) speichert der Job einen Checkpoint. Ein neu gestarteter Worker liest ab dort weiter und nie eine Nachricht doppelt. Ändert sich die Dateiliste, beginnt der Snapshot von vorn.
Duplikate. 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 mit Fundstelle aufgelistet. Dieselbe Nachricht in einem anderen Ordner bleibt erhalten, weil die Ordnerzuordnung eine Information ist, und teilt sich über die Deduplizierung die gespeicherten Chunks. Frühere Importe in dasselbe Postfach zählen mit: Dieselbe Datei zweimal zu importieren ergibt beim zweiten Mal „nichts Neues“ und keinen Snapshot.
Fehler werden aufgelistet. Unlesbare oder beschädigte Elemente (eine kaputte MSG oder EML, ein abgeschnittenes ZIP, eine Nachricht über dem Größenlimit, ein verschlüsseltes oder verschachteltes ZIP) stehen mit Grund im Bericht und sind jeweils in Ihrer Sprache erklärt, siehe Fehlererklärungen. Harmloses (Dateien, die keine Mail sind, leere Dateien, Duplikate) steht als übersprungen mit Fundstelle im Bericht. Nichts fällt stillschweigend weg.
Unlesbar statt Abbruch. Nachrichteninhalte werden in eigenen Hilfsprozessen gelesen (siehe Nicht vertrauenswürdige Dateien). Eine Datei oder Nachricht, deren Lesen zu aufwendig ist oder ihren Hilfsprozess abstürzen lässt, steht mit Grund als unlesbar im Bericht, und der Import läuft mit dem Rest weiter.
Absturzschutz. Bricht der Worker selbst zweimal in Folge bei derselben Datei ab (Speichermangel, Absturz), wiederholt der Import sie nicht endlos: Der Rest dieser Datei steht als unlesbar im Bericht, mit dem Hinweis, sie erneut zu importieren (schon vorhandene Nachrichten werden übersprungen), und der Import läuft mit den übrigen Dateien weiter.
Ohne Metadaten. Eine Nachricht, deren Betreff, Absender und Text sich innerhalb der Grenzen nicht lesen lassen, wird trotzdem Byte für Byte importiert, aber ohne diese Angaben. Der Bericht vermerkt das (metadata_unavailable): Solche Nachrichten sind vollständig, haben aber keine Such- und Anzeigedaten, und die Archivsuche findet ihren Text nicht.
Bericht. Nachrichten, Ordner, Anhänge, Duplikate, übersprungen, fehlgeschlagen und Bytes (gespeichert und gelesen). Je Datei: das Format, der SHA-256 der Quelldatei, die Zähler und das Ergebnis (importiert, teilweise importiert, fehlgeschlagen, nicht importiert). Darunter die Liste der Elemente, Fehler zuerst, höchstens 1.000, der Rest wird gezählt, und feste Hinweise wie „Kalender und Kontakte werden nicht importiert“ und „aus MSG neu aufgebaut“. Der Bericht lässt sich als JSON herunterladen.
Nichts lesbar, nichts gespeichert. Findet ein Lauf nicht eine einzige lesbare Nachricht, entsteht kein leerer Snapshot. Der Job schlägt ohne Wiederholung fehl, und der Bericht mit allen Gründen bleibt einsehbar.

Einen Import zu starten und Dateien hochzuladen erfordert mindestens die Rolle Administrator, einen laufenden Import abzubrechen die Rolle Techniker. Siehe Team und Rollen.

Zusätzlich archivieren (optional)

Setzen Sie den Haken bei zusätzlich ins Archiv übernehmen, wird jede neu importierte Nachricht auch ein Archivobjekt: mit den Original-Bytes (dieselben Chunks wie im Snapshot), einem Platz in der Hash-Kette, den Aufbewahrungsregeln des Archivs und der Suche über Betreff, Adressen und Nachrichtentext (der Inhalt von Anhängen wird nicht durchsucht). Diese Option gibt es in jeder Edition, auch in Community. Siehe Archivierung.

Die Aufbewahrungsfrist beginnt mit dem Importdatum, nicht mit dem Datum der Mail. Eine alte Mail, die heute importiert wird, ist ab heute durch die Hash-Kette geschützt und wird ab heute gezählt. Das Sendedatum der Mail bleibt erhalten und wird in Suche und Anzeige bevorzugt.
Der Schutz des Archivs beginnt mit der Aufnahme. Nur anhängbarer Speicher und Hash-Kette gelten ab dem Moment, in dem Restow das Element hat, nicht ab dem Zeitpunkt, zu dem die Mail ursprünglich gesendet oder empfangen wurde. Was das Speicherziel durchsetzt, steht unter Archivierung und Journaling.
Die Aufnahme ist idempotent: Was schon archiviert ist (gleicher Hash für dasselbe Postfach), wird nicht doppelt angelegt, und ein wiederholter Job setzt fort.

Wiederherstellen aus einem importierten Postfach

Ein importiertes Postfach erscheint im Restore-Explorer wie jedes andere: Ordnerbaum, Suche, Vorschau, Druckansicht und Download. Sie können es in ein bestehendes IMAP-Konto wiederherstellen (per Append mit Flags und Datum, mit Message-ID-Prüfung) oder in ein Microsoft-365-Postfach, wo die Ordnerstruktur unter einem neuen Wiederherstellungsordner landet. Vorhandene Elemente werden nie ersetzt. „Ins Original zurückspielen“ gibt es nicht, weil ein importiertes Postfach kein Original hat.

Export

Starten Sie einen Export im Restore-Explorer (Exportieren …) oder im Archiv, für ein ganzes Postfach, einen Ordner, eine Auswahl oder alle Treffer eines Suchfilters. Quellen sind:

eine Sicherung (ein Microsoft-365-Postfach oder ein IMAP-Konto),
ein importiertes Postfach,
das Archiv, als Auswahl oder Suchfilter.

Format	Was Sie erhalten
EML in einer ZIP-Datei	Eine `.eml` je Nachricht mit der Ordnerstruktur (leere Ordner bleiben), dazu `MANIFEST.csv` (Eintrag, SHA-256, Größe, Message-ID, Datum, Absender, Empfänger, Betreff, Status) und `SHA256SUMS`. Die Bytes sind die gespeicherten Originale.
MBOX (mboxrd)	Ein einzelner Ordner wird eine `.mbox`-Datei. Mehrere Ordner werden eine ZIP-Datei mit einer `.mbox` je Ordner, dazu Manifest und Prüfsummen. Eine Nachricht ohne abschließenden Zeilenumbruch bekommt einen.

SHA256SUMS hat das Format, das sha256sum liest. Entpacken Sie die ZIP-Datei und prüfen Sie jede Nachricht und das Manifest:

sha256sum -c SHA256SUMS

Exportiert wird nur Mail. Kalenderelemente und Kontakte werden gezählt und im Bericht genannt, aber nicht exportiert. Nachrichten, die Microsoft Graph nur in Teilen geliefert hat, haben keine Originaldatei und stehen als nicht exportierbar im Bericht.

Ablauf. Ein Worker-Job baut die Datei und schreibt sie verschlüsselt, in denselben versiegelten Stücken wie beim Upload, in das Speicherziel des Mandanten. Im Speicher liegen höchstens eine Nachricht und ein Stück. Beim Streamen wird der SHA-256 jeder Nachricht gegen das Manifest geprüft: Ein beschädigter Chunk bricht den Export ab, statt eine still fehlerhafte Datei zu liefern. Die fertige Datei lässt sich 24 Stunden herunterladen (EXPORT_TTL_HOURS), danach löscht der Retention-Lauf sie. Der SHA-256 der fertigen Datei steht in der Oberfläche und im Audit-Eintrag.

Export-Budget. Alle noch nicht abgelaufenen Exportdateien eines Mandanten dürfen zusammen EXPORT_MAX_TENANT_BYTES belegen, standardmäßig 50 GiB. Eine neue Anfrage bei ausgeschöpftem Budget wird abgewiesen (export-quota-exceeded), und die Antwort nennt Belegung, Grenze und wann ältere Exporte ablaufen. Ein Export, der während des Laufs über das Budget wächst, bricht ab, entfernt, was er geschrieben hat, und schlägt mit „Der Export ist größer als der Platz für Exporte“ fehl (Fehlercode export.quota_exceeded), mit den nächsten Schritten: den Ablauf älterer Exporte abwarten, weniger Post auf einmal exportieren oder die Grenze anheben. Die Reste fehlgeschlagener oder abgebrochener Exporte entfernt der Retention-Lauf eine Stunde nach Ende des Jobs.

Audit. Die Anfrage und jeder Download stehen im Audit-Log als export.requested und export.downloaded, ein Abbruch als export.cancelled. Bei fremden Daten trägt der Eintrag Ihre Begründung und in wessen Auftrag es geschah. Siehe Audit-Log. Einen Export anzufordern und herunterzuladen erfordert mindestens die Rolle Techniker.

Sicherheit und Grenzen

Erkennung nach Inhalt. Einer Datei wird nie wegen ihres Namens vertraut.
ZIP-Schutz. Höchstens 2 Mio. Einträge, 256 GiB entpackt und ein Kompressionsfaktor von 1.000. Verschlüsselte und verschachtelte Archive werden gemeldet und nicht geöffnet. Einträge werden nie auf eine Platte geschrieben, und Namen werden bereinigt (.., absolute Pfade, Backslashes).
Eine Nachricht nach der anderen. Eine einzelne Nachricht (eine EML, eine MSG, eine Nachricht einer MBOX) wird in den Speicher gelesen, begrenzt durch IMPORT_MAX_MESSAGE_BYTES (256 MiB). Größere werden gemeldet.
Alles wird protokolliert: import.upload.created, import.upload.completed, import.upload.cancelled, import.requested, import.cancelled und die drei Export-Ereignisse oben.
Speicherbedarf. Das Staging braucht die Größe der Dateien bis zum Ende des Imports, danach liegen die Nachrichten dedupliziert im Chunk-Store. Exporte belegen Platz bis zu ihrem Ablauf. Beides begrenzen das Staging- und das Export-Budget je Mandant.
Staging und Exporte gehören Restow. Legen Sie keine eigenen Dateien unter tenants/<Mandanten-ID>/staging oder tenants/<Mandanten-ID>/exports im Speicherziel ab: Der Retention-Lauf entfernt, was kein Upload und kein Export kennt.

Nicht vertrauenswürdige Dateien werden in Hilfsprozessen gelesen

Wer Mail importiert oder eine Nachricht in einem Postfach hinterlegt, das Restow sichert, bestimmt die Bytes, die Restow liest. Restow wertet Mailinhalte deshalb nie im Worker- oder API-Prozess selbst aus. Der MSG-Leser, der Leser für die Angaben einer Nachricht (Betreff, Absender, Text), die Vorschau und der Anhang-Download im Restore-Explorer sowie der Journal-Empfang des Archivs laufen in eigenen Hilfsprozessen mit Speicher- und Zeitgrenze. Ein Hilfsprozess, dem Zeit oder Speicher ausgehen, wird beendet. Das Element gilt dann als unlesbar, und Worker oder API arbeiten weiter.

Import (Worker). Die Struktur einer MSG-Datei (Kopf, Zuordnungstabellen, Verzeichnis, Größen, Schleifen, Zahl der Einträge, Tiefe) wird geprüft, bevor der MSG-Leser sie sieht. Eine Datei, die die Prüfung nicht besteht, steht als unlesbar im Bericht und wird nie ausgewertet. Gleichzeitig laufen IMPORT_PARSE_WORKERS Hilfsprozesse.
Vorschau und Anhang-Download (API). Siehe Backup und Restore. Gleichzeitig laufen PREVIEW_PARSE_WORKERS Hilfsprozesse, gemeinsam mit dem Journal-Empfang, und PREVIEW_TIMEOUT_MS begrenzt die formatierte Ansicht einer Nachricht.
Journal-Empfang (API). Siehe Exchange-Journaling.
Arbeitsspeicher. Eine Nachricht bis 8 MiB wird in einem wiederverwendeten Hilfsprozess gelesen, der bis zu 512 MB belegen darf. Eine größere Nachricht bekommt einen eigenen Prozess, bei den größten mit bis zu 3 GB. Planen Sie den Arbeitsspeicher der Container worker und api entsprechend. Auf einem kleinen Host setzen Sie IMPORT_PARSE_WORKERS und PREVIEW_PARSE_WORKERS auf 1.

Bekannte Grenzen

Ein importiertes Postfach lässt sich in 0.4.7 nicht löschen, ebenso wenig die Quelle Importierte Mail-Dateien, solange sie Snapshots, Archivobjekte oder Legal Holds hält. Ältere Snapshots räumt die Backup-Retention, der neueste bleibt.
MSG. Ein Körper, der nur als RTF (oder RTF-verpacktes HTML) vorliegt, wird nicht dekodiert, Restow nimmt dann den Text-Körper. Anhänge, die nur auf eine Datei verweisen, entfallen. Ein eingebettetes Element, das keine Mail ist, bleibt ein .msg-Anhang. Die Kopfzeilen kommen, wenn vorhanden, unverändert aus den Transportkopfzeilen der MSG, ein nachträglich in Outlook geänderter Betreff steht dort also nicht. Der MSG-Leser läuft hinter der Strukturprüfung in einem Hilfsprozess mit Zeit- und Speichergrenze, und eine beschädigte oder bösartige MSG steht als unlesbar im Bericht. Die Strukturprüfung ist eine Schutzprüfung, kein vollständiger Validator: Eine Datei, die sie besteht und den Leser trotzdem überfordert, kostet ihren Hilfsprozess, nicht den Import.
MBOX. Die Variante mboxrd wird zurückgenommen (ein führendes > vor From -Zeilen). Bei mboxo-Dateien, die >From schon im Original enthielten, lässt sich beides nicht unterscheiden. \Deleted aus X-Status wird nicht übernommen, die Nachricht wird importiert.
UTF-16-kodierte EML-Dateien werden nicht als EML erkannt.
Metadaten (Betreff, Absender, Nachrichtentext) liest ein Mail-Parser in einem Hilfsprozess, das dauert bei sehr großen Nachrichten entsprechend länger. Eine Nachricht, die die Grenzen überschreitet, wird ohne Betreff, Absender und Text importiert (Hinweis metadata_unavailable im Bericht). Der Import speichert die Bytes unabhängig davon unverändert.
Ein Wechsel des primären Speicherziels kopiert Staging- und Export-Dateien nicht mit, weil sie temporär sind. Ein unfertiger Upload muss danach wiederholt werden.

Konfiguration

Setzen Sie diese Werte in der .env (siehe Umgebungsvariablen). Ein leerer Wert verwendet den Standard.

Variable	Bedeutung	Standard
`RESTOW_IMPORT_DIR`	Host-Verzeichnis, das schreibgeschützt unter `/var/lib/restow/import` in `api` und `worker` eingehängt wird. Jeder Mandant nutzt den Unterordner `<Verzeichnis>/<Mandanten-Slug>/`, den Sie selbst anlegen.	`./import` neben der `docker-compose.yml`
`IMPORT_DIR`	Pfad innerhalb der Container. Ändern Sie ihn nur zusammen mit dem Mount.	`/var/lib/restow/import`
`IMPORT_MAX_FILE_BYTES`	Größte Datei, die der Upload annimmt, in Bytes.	10 GiB
`IMPORT_UPLOAD_TTL_HOURS`	Wie lange ein unfertiger oder ungenutzter Upload aufbewahrt wird.	48
`IMPORT_SEGMENT_BYTES`	Größe eines Upload-Stücks in Bytes (erlaubt 64 KiB bis 32 MiB).	8 MiB
`IMPORT_MAX_MESSAGE_BYTES`	Größte einzelne Nachricht, die in den Speicher gelesen wird.	256 MiB
`IMPORT_MAX_STAGING_BYTES`	Staging-Budget je Mandant in Bytes: die angekündigten Größen aller Uploads, deren Stücke noch liegen, bis ihr Import beendet ist.	100 GiB
`IMPORT_PARSE_WORKERS`	Hilfsprozesse des `worker`, die gleichzeitig auswerten (MSG, Angaben einer Nachricht), 1 bis 8.	2
`EXPORT_TTL_HOURS`	Stunden, die ein fertiger Export herunterladbar bleibt, bevor seine Datei gelöscht wird.	24
`EXPORT_MAX_TENANT_BYTES`	Bytes, die alle noch nicht abgelaufenen Exportdateien eines Mandanten zusammen belegen dürfen.	50 GiB
`PREVIEW_PARSE_WORKERS`	Hilfsprozesse der `api`, die gleichzeitig auswerten (Vorschau, Anhang-Download, Journal-Reports), 1 bis 8.	2
`PREVIEW_TIMEOUT_MS`	Wie lange die formatierte Vorschau einer Nachricht dauern darf, in Millisekunden. Der Versuch nur mit Text bekommt die Hälfte.	10000

Geplant

PST- und OST-Import, PST-Export, MSG-Export (sobald ein Schreiber mit geklärter Lizenz existiert), Kalender und Kontakte aus MSG und PST, das Lesen des eigenen MailStore-Archivformats (falls es offen dokumentiert wird) und passwortgeschützte ZIP-Dateien. Siehe die Roadmap.