Benutzer-Werkzeuge

Webseiten-Werkzeuge


duplikatserkennung

Soweit E-Mails mehrfach zur Archivierung an Benno MailArchiv geliefert werden, greift die Doubletten- bzw. Duplikatserkennung von Benno MailArchiv.

Doubletten- bzw. Duplikats-Erkennung

Beim Archivieren erzeugt Benno MailArchiv über jede archivierte E-Mail eine SHA256-Prüfsumme (Checksumme). Diese wird im intern im Benno MailArchiv Journal protokolliert und für Konsistenzprüfungen (Compliance) verwendet.

Funktionsweise

Die Checksumme wird jeweils über die gesamte eingegangene E-Mail erzeugt. Von der Berechnung der Checksumme ausgenommen sind Header, die in der Konfigurationsdatei als <secretheaders /> deklariert sind. In der Regel sind diese Header von der Import-Schnittstelle hinzugefügt worden. Sie waren daher nie Bestandteil der eigentlichen E-Mail.

Beim Archivieren einer E-Mail wird geprüft, ob eine Mail mit gleicher Prüfsumme evtl. bereits im Archiv vorhanden ist. Eine gleiche Checksumme bedeutet, dass die zu archivierende Mail bereits im Archiv abgelegt wurde, also eine Doublette wäre. Die Archivierung der betreffenden Mail würde in diesem Fall abgebrochen und das Erkennen des Duplikats entsprechend im Archivierungs-Logfile /var/log/benno/archive.log protokolliert. Zusätzlich wird der nicht erfolgte Archivierungsvorgang des Duplikats im Journal (/srv/benno/archive/repo/{yyyy}/journal/current.journal) mit Prüfsumme und dem Hinweis „DUPLICATE“ protokolliert.

Dank dieser wirksamen Doubletten-Erkennung können E-Mails beliebig oft zur Archivierung an Benno MailArchiv übergeben werden. Sie werden zuverlässig als Doubletten erkannt und ihre Archivierung als Duplikat abgebrochen, so dass jede Mail tatsächlich nur einmal in das Mailarchiv gelangt. Durch die SHA256-Prüfsumme ist mit an Sicherheit grenzender Wahrscheinlichkeit ausgeschlossen, dass E-Mails jemals versehentlich als Doublette erkannt und damit irrtümlich nicht archiviert werden. Da die gesamte E-Mail für die Erzeugung der Checksumme herangezogen wird, bedeutet dies bzgl. der Konsistenzprüfung von archivierten E-Mails bzw. der Konsistenzprüfung des gesamten Archivs, dass bereits das „Kippen“ eines einziges Bits einer archivierten E-Mail ausreicht, um die Checksumme der Mail zu verändern, und somit eine Korruption der Mail/des Archivs festzustellen ist.

Multiple Mailzuführung in komplexen Umgebungen

Während E-Mails in der Regel (und insbes. in on premise Installationen) über einen einzigen, uniformen Weg ins Mailarchiv gelangen, kann es in komplexen Umgebungen (bspw. in größeren Hosting-Infrastrukturen) vorkommen, dass E-Mails mehrfach und dabei gleichzeitig über verschiedene Wege zum Archiv transportiert werden. Bspw. könnten unterschiedliche MTAs oder Transportwege und -arten (SMTP, IMAP etc.) dafür verantwortlich sein.

In diesem Fall bietet sich die Konfiguration einer vereinfachten Checksumme über einzelne Header der E-Mail an.

Ein Beispiel

In einer sehr komplexen Infrastruktur wird Benno MailArchiv eine konkrete E-Mail „M“ über drei unterschiedliche Wege zum Archivieren zugestellt. Durch den Transport eines jeden Exemplars der E-Mail über jeweils unterschiedliche Wege ist zwar die Mail (aus Sicht des Anwenders im Mailclient – also textlich-inhaltlich) die gleiche, aber in den Mail-Exemplaren (im für den Anwender i.d.R. nicht sichtbaren Teil) wurden durch die verschiedenen Transportwege je Mail-Exemplar individuelle und unterschiedliche Mailheader eingefügt.

Die drei (eigentlich und aus Anwendersicht identischen) E-Mails sind aus Sicht der Doubletten- bzw. Duplikats-Erkennung von Benno MailArchiv drei unterschiedliche Mails: Wird über jeder der drei E-Mail-Exemplare die SHA256-Checksumme erzeugt, erhalten wir die Checksummen „C1“, „C2“ und „C3“. Inhaltlich (bzw. textlich und aus Anwendersicht) scheinen die Mails identisch zu sein. Auf Grund der unterschiedlichen Header jeder der Mail-Exemplare erkennt Benno MailArchiv sachlogisch jedoch richtigerweise drei unterschiedliche E-Mails (da unterschiedlichen Prüfsummen). Benno MailArchiv würde die drei Mail-Exemplare dementsprechend als drei unterschiedliche Mails archivieren. Aus Anwendersicht wären sie damit quasi dreimal im Archiv sichtbar, da sie bezogen auf den Mailbody über die gleichen Suchkriterien gefunden und angezeigt würden.

Um in dieser Situation dennoch eine geeignete Umsetzung (jede Mail nur einmal archivieren) zu erreichen, bietet sich das folgende Szenario an:

Eine E-Mail ist durch die nachstehend genannten Header und zusätzlich durch den Body (Nachrichtentext) der Mail eindeutig gekennzeichnet bzw. identifizierbar:

Envelope-From - X-REAL-MAILFROM
Envelope-To - X-REAL-RCPTTO
Return-Path
Subject
Message-Id
Date
From
To
Cc
Body

Zwei E-Mails M1 und M2, die sich in Bezug auf die vorgenannten Merkmale nicht unterscheiden, sind hinsichtlich Inhalt und Zuordnung von Absender- und Empfänger identisch. Weicht eines dieser Felder ab, sind die beiden Mails M1 und M2 nicht identisch.

Andere Mailheader wie z.B. Received, DKIM-Signaturen usw. haben nicht unmittelbar mit dem Inhalt der E-Mail zu tun. Diese Header sind eher Teil des Envelopes einer E-Mail (ähnlich wie Stempel und Post-Its an einem Vertrag, der durch ein Unternehmen läuft).

Auf Basis dieser Situation würde die Berechnung der Checksummen in zweifacher Form erfolgen. Zunächst würde (wie bisher) die für die Umsetzung der Compliance Policies erforderliche normale Checksumme über die gesamte E-Mail erzeugt. Parallel würde zusätzlich eine zweite Checksumme ausschließlich über den oben spezifizierten Teil der E-Mail erzeugt. Damit wäre eine Doubletten-Erkennung für aus Anwendersicht gleiche E-Mails einfach erreicht.

Compliance-Anforderungen seitens der GoBD

Laut GoBD muss jede Mail im Originalzustand aus dem Archiv wiederhergestellt werden können (also die Mail incl. aller Header, Attachments usw.). Desweiteren muss jede Mail hinsichtlich etwaiger Manipulationen prüfbar sein, was über die normale Checksumme abgebildet wird.

Wenn aber mehrere (inhaltlich-textlich gleiche) Mails M1, M2 und M3 (im obigen Sinne unterschiedlicher Exemplare der gleichen E-Mail) zur Archivierung anlanden, wie ist mit diesen in Bezug auf die unterschiedlichen Header zu verfahren?

Eine Sicht auf rechtliche Aspekte dieser Situation

Rechtlich besteht nach uns vorliegenden Informationen kein Zwang, mehrere Varianten einer E-Mail zu archivieren, die sich nur in Bezug auf die Mailheader unterscheiden. Dennoch sollten nach den uns vorliegenden Informationen pragmatisch betrachtet alle Exemplare der betreffenden E-Mail (M1, M2, M3 usw.) archiviert werden. Rein formell (und technisch anhand der unterschiedlichen Checksummen sofort nachvollziehbar) handelt es sich de facto um unterschiedliche E-Mails. Aus Gründen der rechtlichen Sicherheit sollten daher alle Versionen der E-Mail archiviert werden. Technisch wäre es anhand zweier Checksummen, also der oben beschriebenen vereinfachten Duplikatserkennung, einfach realisierbar, dass nur das erste der inhaltlich-textlich gleichen Mail-Exemplare archiviert würde.

Um hier eine für den Betreiber rechtssichere Lösung zu implementieren, raten wir dazu, den Sachverhalt vor der Umsetzung mit einem Rechtsbeistand eigener Wahl zu erörtern und erst danach die Form der konkreten Umsetzung der Doubletten-Erkennung zu entscheiden und umzusetzen.

Wir gehen bis auf weiteres davon aus, dass es rechtlich ausreichend sein könnte, die vereinfachte Doubletten- bzw. Dupplikatss-Erkennung anzuwenden und damit nur eines von mehrfach anlandenden E-Mail-Exemplaren zu archivieren. Wir gehen außerdem und bis auf weiteres davon aus, dass eine geeignete Erklärung bzw. Niederschrift des Sachverhalts in der (dank GoBD obligatorischen) Verfahrensdokumentation ausreichend sein dürfte, um zu einer rechtssicheren Archivierung zu gelangen.

Die Entscheidung über die Art der angewendeten Doubletten-Erkennung und damit verbunden die Verantwortung gegenüber der Finanzverwaltung obliegt einzig und allein dem Betreiber.

Rechtlicher Hinweis / Haftungsauschluss / Disclaimer

Dieses Dokument stellt keine Rechtsberatung dar. Es dient lediglich zur allgemeinen Information. Wir übernehmen keine Gewähr für die Richtigkeit oder Vollständigkeit der Angaben. Jegliche Haftung ist ausgeschlossen.

duplikatserkennung.txt · Zuletzt geändert: 2022/06/08 14:12 von lwsystems