# Verfahrensdokumentation — E-Mail-Archivierung mit MailVault *Vorlage. Die technischen Abschnitte beschreiben, was die Software tatsächlich tut; die organisatorischen Abschnitte sind von der archivierenden Stelle auszufüllen. Die GoBD (Rz. 151–155) verlangen eine solche Dokumentation. Die GeBüV verlangt Arbeitsanweisungen, die Organisation, Zuständigkeiten, Abläufe und Infrastruktur beschreiben (Art. 4), und bei veränderbaren Datenträgern, dass die Abläufe und Verfahren festgelegt und dokumentiert sind (Art. 9 Abs. 1 lit. b Ziff. 4).* *Wo diese Vorlage Menüs und Einstellungen nennt, sind es die Bezeichnungen der deutschen Programmoberfläche.* | | | |---|---| | Unternehmen | `[Firma, Adresse, UID]` | | Verantwortlich | `[Name, Funktion]` | | Archivsystem | MailVault, Format-Version `[aus archive.json, derzeit 3]` | | Archiv-Kennung | `[archiveID aus archive.json]` | | Gültig ab | `[Datum]` | | Version dieser Dokumentation | `[1.0]` | --- ## 1. Zweck und Geltungsbereich Archiviert wird die geschäftliche E-Mail-Korrespondenz der unter `[Konten auflisten]` geführten Postfächer. Grundlage ist: * **Schweiz:** OR Art. 957a und 958f, GeBüV — Geschäftsbücher und Buchungsbelege sind zehn Jahre aufzubewahren (OR Art. 958f Abs. 1). Als Buchungsbeleg gilt jede Aufzeichnung, die nötig ist, um einen Geschäftsvorfall nachvollziehen zu können (OR Art. 957a Abs. 3), auch eine E-Mail. Die GeBüV regelt, wie: Integrität (Art. 3), Dokumentation (Art. 4), Verfügbarkeit (Art. 6), zulässige Informationsträger (Art. 9) und deren regelmässige Prüfung (Art. 10). * **Deutschland:** HGB § 257, AO § 147, GoBD — empfangene und abgesandte Handels- und Geschäftsbriefe sechs Jahre, Buchungsbelege acht Jahre (seit dem 1. Januar 2025; bei Kredit-, Versicherungs- und Wertpapierinstituten zehn Jahre), Bücher und Abschlüsse zehn Jahre; Nachvollziehbarkeit, Vollständigkeit, Unveränderbarkeit, maschinelle Auswertbarkeit. * **EU:** DSGVO Art. 17 — Löschung personenbezogener Daten auf Verlangen, soweit keine gesetzliche Aufbewahrungspflicht oder ein Rechtsstreit entgegensteht. * `[weitere, z. B. SEC Rule 17a-4, falls einschlägig]` ## 2. Erfassung E-Mails werden **lesend** vom IMAP-Server geholt. Das Postfach wird mit `EXAMINE` geöffnet, nie mit `SELECT`; Nachrichten werden mit `BODY.PEEK[]` gelesen. Dadurch werden weder Gelesen-Status noch `\Recent` verändert. Der IMAP-Client verweigert jeden verändernden Befehl (`STORE`, `APPEND`, `EXPUNGE`, `COPY`, `MOVE`, `CREATE`, `DELETE`, `RENAME`, `SELECT`), bevor ein Byte das Gerät verlässt. Erfasst wird die Nachricht **im Originalzustand** (RFC 5322, Byte für Byte wie zugestellt), zusammen mit Postfach, IMAP-UID, Flags und Zustellzeitpunkt. | | | |---|---| | Erfassungsintervall | `[z. B. täglich 02:00]` | | Erfasste Postfächer | `[Liste]` | | Ausgenommene Ordner | `[z. B. Junk, Papierkorb — mit Begründung]` | | Verantwortlich für die Durchführung | `[Name]` | ## 3. Speicherung * Nachrichten liegen in fortlaufend geschriebenen **Pack-Dateien**. Eine abgeschlossene Pack-Datei wird mit SHA-256 geprüft und mit dem macOS-Schutz `uchg` gegen versehentliche Änderung geschützt (für GeBüV und GoBD standardmässig eingeschaltet). Ein Administrator kann diesen Schutz aufheben; ein unveränderbarer Datenträger im Sinne von GeBüV Art. 9 Abs. 1 lit. a ist die Festplatte damit nicht. Sie ist ein veränderbarer Datenträger nach lit. b, und die Unveränderbarkeit wird nachgewiesen statt vorausgesetzt: durch Prüfsummen, Hash-Kette, Siegel und Zeitstempel (Abschnitt 4). * Jede Nachricht ist einzeln komprimiert (deflate mit trainiertem Wörterbuch, LZFSE oder LZMA — je nachdem, was kleiner ausfällt) und einzeln adressierbar. * Identische Anhänge werden inhaltsadressiert **einmal** gespeichert. Die Nachricht selbst bleibt davon unberührt: sie wird beim Lesen byteidentisch wieder zusammengesetzt und gegen den bei der Erfassung gebildeten SHA-256 geprüft. * Metadaten und Volltextindex liegen in einer SQLite-Datenbank. Diese ist ein **abgeleiteter Index**: sie lässt sich jederzeit vollständig aus den Pack-Dateien neu aufbauen (`mailvault rebuild-catalog`). | | | |---|---| | Speicherort | `[Pfad, Gerät]` | | Dateisystem | `[APFS o. ä. — Netzlaufwerke sind nicht zulässig]` | | Datensicherung | `[Verfahren, Intervall, Aufbewahrungsort]` | | Zweitexemplar | `[Ort, Datenträger; Wiederherstellung zuletzt erfolgreich getestet am]` | Wo das Zweitexemplar liegt, wird im Programm unter *Aufbewahrungsrichtlinie ▸ Organisation* festgehalten (oder `mailvault policy --second-copy `); der Compliance-Bericht fragt danach, bis es erfasst ist (GeBüV Art. 5). Für SEC 17a-4 ist ein getrennt gelagertes Zweitexemplar Pflicht. ## 3a. Was das System von sich aus **nicht** tut Für die Beurteilung der Ordnungsmässigkeit ist ebenso wichtig, was nicht geschieht: * Es löscht nichts selbsttätig, weder nach Fristablauf noch nach Zeitplan. * Es verändert auf dem Mailserver nichts. Postfächer werden mit `EXAMINE` geöffnet, Nachrichten mit `BODY.PEEK` gelesen; der Client verweigert jeden verändernden Befehl, bevor er das Gerät verlässt. * Es lädt beim Anzeigen einer HTML-Nachricht keine entfernten Inhalte nach. Bilder, Zählpixel und Schriften bleiben blockiert, sodass das Öffnen einer archivierten Nachricht dem Absender nichts mitteilt und keine Spur bei Dritten hinterlässt. * Es verändert archivierte Nachrichten nicht. Deduplizierung und Komprimierung wirken unterhalb der Nachricht; die Wiederherstellung ist bytegleich und wird gegen den bei der Erfassung gebildeten SHA-256 geprüft. ## 4. Unveränderbarkeit und Integritätsnachweis 1. **Pro Nachricht** wird bei der Erfassung ein SHA-256 über die Originalbytes gebildet und gespeichert. 2. **Jede Handlung** (Erfassung, Suche, Export, Löschung, Aufbewahrungslauf, Legal Hold, Prüfung) wird in ein **hash-verkettetes Journal** geschrieben. Jeder Eintrag bindet seinen Vorgänger ein; jede Änderung, Umstellung oder Entfernung eines Eintrags wird beim Nachrechnen erkannt. 3. **Siegel:** In regelmässigen Abständen wird der Kettenkopf mit einem Ed25519-Schlüssel signiert. Der öffentliche Schlüssel liegt jedem Siegel bei und kann der Prüferin separat übergeben werden. 4. **Zeitstempel:** Jedes Siegel trägt zusätzlich einen Zeitstempel einer unabhängigen Zeitstempelstelle nach RFC 3161 (standardmässig SwissSign, ersatzweise DigiCert). Er belegt, dass der Kettenkopf zu diesem Zeitpunkt bestand, und macht den Zeitpunkt der Speicherung unverfälschbar nachweisbar (GeBüV Art. 9 Abs. 1 lit. b Ziff. 2) — die Uhr des eigenen Rechners könnte jeder Administrator zurückstellen. War die Stelle beim Siegeln nicht erreichbar, weist der Compliance-Bericht das Siegel ohne Zeitstempel aus. 5. **Prüfung:** `mailvault verify --deep` liest jede Nachricht neu, setzt sie aus dem Speicher zusammen und vergleicht sie mit dem ursprünglichen Hash; zusätzlich werden Kette, Siegel, Pack-Prüfsummen und die Datenbank geprüft. 6. **Kontrolle:** `mailvault control --by ` — oder im Programm *Archiv ▸ Kontrollbericht…* — führt diese Prüfung durch, hält Person, Datum und Ergebnis in der Kette fest und erstellt einen datierten Kontrollbericht zur Unterschrift. Das ist die regelmässige Prüfung der Informationsträger auf Integrität und Lesbarkeit nach GeBüV Art. 10 Abs. 1; der Compliance-Bericht mahnt sie an, wenn die letzte älter als ein Jahr ist. | | | |---|---| | Prüfintervall | `[z. B. quartalsweise, Kontrolle mit Bericht mindestens jährlich]` | | Verantwortlich für die Prüfung | `[Name]` | | Ablage der unterschriebenen Kontrollberichte | `[Ort]` | | Zeitstempelstelle | `[aus dem Compliance-Bericht]` | | Fingerabdruck des Signaturschlüssels | `[SHA-256 aus dem Compliance-Bericht]` | ## 5. Schlüsselverwaltung Ist die kryptografische Löschung aktiviert (bei DSGVO-Konfiguration standardmässig), wird jeder Nachrichteninhalt mit einem eigenen AES-256-GCM-Schlüssel verschlüsselt. Diese Schlüssel liegen, mit einem Hauptschlüssel umschlossen, in `keys/`. > **Ohne `keys/master.key` sind die Nachrichteninhalte nicht mehr lesbar.** > Der Schlüssel ist getrennt vom Archiv zu sichern. | | | |---|---| | Aufbewahrungsort der Schlüsselkopie | `[Tresor, Passwortmanager, Ort]` | | Zugriffsberechtigte | `[Namen]` | | Prüfung der Schlüsselkopie | `[Intervall]` | ## 6. Aufbewahrungsfristen und Vernichtung Die Frist beginnt mit dem Ende des Jahres, in das die Nachricht fällt: nach Schweizer Recht mit dem Ende des **Geschäftsjahres** (OR Art. 958f Abs. 1), nach deutschem mit dem Ende des **Kalenderjahres** (AO § 147 Abs. 4, HGB § 257 Abs. 5), unabhängig vom Geschäftsjahr. Sind beide Regelwerke eingeschaltet, gilt das spätere Ende. | | | |---|---| | Das Geschäftsjahr endet am | `[z. B. 31. Dezember]` — erfasst unter *Aufbewahrungsrichtlinie ▸ Regelwerke* | Wird das Ende des Geschäftsjahres oder eine Frist geändert, berechnet MailVault das Aufbewahrungsdatum jeder archivierten Nachricht neu und hält die Änderung in der Kette fest. | Klasse | Frist in MailVault | Anwendung | |---|---|---| | Geschäftskorrespondenz | 10 Jahre | Standard | | Buchungsbeleg | 10 Jahre¹ | `[Kriterium]` | | Vertrag | 10 Jahre | `[Kriterium]` | | Personalakte | 10 Jahre | `[Kriterium]` | | Ohne Aufbewahrungspflicht | 1 Jahr | `[Kriterium]` | ¹ Schweiz: zehn Jahre (OR Art. 958f Abs. 1). Deutschland: seit dem 1. Januar 2025 acht Jahre (AO § 147 Abs. 3, HGB § 257 Abs. 4), bei Kredit-, Versicherungs- und Wertpapierinstituten zehn Jahre. Gelten mehrere Regelwerke, hält MailVault die längste Frist ein; für GeBüV und GoBD bewahrt es jede Nachricht mindestens zehn Jahre auf. **Es findet keine automatische Löschung statt — in keiner Konfiguration.** Ein Fristablauf ist eine Erlaubnis zur Vernichtung, keine Anweisung dazu. Das System kennt zwei Einstellungen und keine dritte: * `reportOnly` (Standard): abgelaufene Nachrichten werden aufgelistet, nichts wird vernichtet. * `manualApproval`: eine Person kann vernichten, nachdem sie die Liste geprüft hat. Der Ablauf im Fall `manualApproval`: 1. `mailvault retention ` — oder im Programm unter *Compliance ▸ Aufbewahrung* — listet auf, was die Frist überschritten hat. Dieser Schritt vernichtet nichts. 2. Die verantwortliche Person prüft die Liste. 3. `mailvault retention --dispose --approved-by "" --reason "" --confirm DISPOSE` vernichtet **genau die geprüften Nachrichten**. Name, Grund und jede einzelne Nachricht gehen in die Integritätskette. 4. Jede Nachricht wird im Moment der Vernichtung erneut geprüft: ein zwischenzeitlich gesetzter Legal Hold oder eine verschobene Frist nimmt sie wieder heraus. Die Vernichtung erfolgt durch Zerstörung des Nachrichtenschlüssels; die Datenträger werden nicht überschrieben, die Integritätskette bleibt vollständig. | | | |---|---| | Einstellung | `[reportOnly / manualApproval]` | | Auslösung | `[manuell durch wen, in welchem Turnus geprüft]` | | Freigabe der Vernichtung | `[Name, Funktion]` | | Ablage der Freigaben | `[Ort — die Kette protokolliert sie ohnehin]` | ## 7. Auskunft, Löschbegehren und Legal Hold * **Auskunft (DSGVO Art. 15):** Suche nach der betroffenen Adresse, Export als portables Paket oder als `.eml` mit Index. * **Löschung (DSGVO Art. 17):** Zweistufig, wie die Aufbewahrungsvernichtung. `mailvault request --participant ` — oder im Programm *Archiv ▸ Betroffenenanfrage…* — zeigt, was das Archiv über die Person enthält, was unter Legal Hold steht und wie viele Nachrichten **noch innerhalb ihrer gesetzlichen Aufbewahrungsfrist** liegen. Erst eine namentliche Freigabe mit Begründung und getippter Bestätigung führt die Löschung aus. Nachrichten unter einem aktiven Legal Hold werden **verweigert** — Art. 17 Abs. 3 lit. b und e sehen das ausdrücklich vor. Nachrichten innerhalb der Aufbewahrungsfrist werden nicht verweigert, aber gesondert ausgewiesen: ihre Löschung setzt eine gesetzliche Aufbewahrungspflicht ausser Kraft und ist entsprechend zu begründen. Antrag, Freigabe, Grund und jede betroffene Nachricht stehen in der Integritätskette. * **Legal Hold:** Friert die betroffene Korrespondenz ein; Aufbewahrungsvernichtung und Löschung werden abgelehnt, bis der Hold aufgehoben wird. | | | |---|---| | Zuständig für Betroffenenanfragen | `[Name]` | | Frist für die Bearbeitung | `[z. B. 30 Tage]` | | Zuständig für Legal Holds | `[Name, meist Rechtsabteilung]` | ## 8. Auswertbarkeit und Datenzugriff Für die Prüferin stehen zur Verfügung: * **Export** mit den Originalnachrichten sowie `index.csv` und `index.json` (Datenzugriff Z3), dem vollständigen Journal, allen Siegeln und einer Anleitung, wie beides ohne MailVault nachgerechnet wird. * **Portables Paket** — `.eml`-Dateien plus eine HTML-Seite, die die Auswahl auf jedem Rechner ohne Installation, ohne Server und ohne Netzwerk durchsucht und liest. * **Format-Dokumentation** (`docs/ARCHIVE-FORMAT.md`), damit das Archiv auch ohne die Software auswertbar bleibt. ## 9. Änderungen an diesem Verfahren Jede Änderung der Aufbewahrungsrichtlinie wird mit Begründung in der Integritätskette festgehalten. Änderungen an dieser Dokumentation sind hier zu führen: | Datum | Version | Änderung | Verantwortlich | |---|---|---|---| | `[…]` | `[…]` | `[…]` | `[…]` | ## 10. Notfall und Wiederherstellung | Fall | Vorgehen | |---|---| | Datenbank beschädigt | `mailvault rebuild-catalog` — oder *Archiv ▸ Katalog aus den Pack-Dateien neu aufbauen…*. Baut den Index vollständig aus den Pack-Dateien neu auf, samt Postfachzuordnung, Aufbewahrungsdaten und Legal Holds. Die beschädigte Datenbank bleibt als `catalog.sqlite.broken-` erhalten | | Suchindex unbrauchbar | `mailvault reindex` | | Archiv verloren | Wiederherstellung aus der Datensicherung, anschliessend `mailvault verify --deep` | | Hauptschlüssel verloren | Inhalte sind unwiederbringlich. Schlüsselkopie einspielen | | Integritätsprüfung schlägt fehl | Vorfall dokumentieren, letzte gültige Sicherung einspielen, Ursache klären, `[Meldeweg]` | --- *Diese Vorlage ist keine Rechtsberatung. Die Eignung für die konkrete Aufbewahrungspflicht ist mit der Revisionsstelle oder dem Steuerberater abzustimmen.*