Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- duplikatserkennung [2018/07/02 15:56] – [Multiple Mailzuführung in komplexen Umgebungen] lwsystems
+++ duplikatserkennung [2026/09/14 14:23] (aktuell) – [Ein Beispiel] lwsystems
@@ Zeile 7: / Zeile 7: @@
 ===== Funktionsweise =====
-Die Checksumme wird jeweils über die **gesamte** E-Mail erzeugt. So kann direkt beim Archivieren einer E-Mail geprüft werden, ob eine Mail mit gleicher Prüfsumme evtl. bereits im Archiv vorhanden ist. Eine etwaige gleiche Checksumme würde bedeuten, 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 mit Prüfsumme und dem Hinweis „DUPLICATE“ protokolliert.
+Die Checksumme wird jeweils über die **gesamte** eingegangene E-Mail erzeugt. Von der Berechnung der Checksumme ausgenommen sind Header, die in der Konfigurationsdatei als //[[konfiguration#secretheaders|<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 SHA265-Prüfsumme ist mit an Sicherheit grenzender Wahrscheinlichkeit ausgeschlossen, dass E-Mails jemals versehentlich als Doublette erkannt und damit irrtümlich nicht archiviert werden.
+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.
@@ Zeile 17: / Zeile 19: @@
 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.
+In diesem Fall bietet sich die Konfiguration einer [[konfiguration#vereinfachte_checksumme|vereinfachten Checksumme]] über einzelne Header der E-Mail an.
-====== Vereinfachte Checksumme ======
-Die Berechnung dieser Checksumme wird mit dem Tag //<customhash />// in der Konfigurationsdatei ''/etc/benno/benno.xml'' konfiguriert.
-<code xml>
-               <senderheaders>
-               ...
-               </senderheaders>
-               <recipientheaders>
-               ...
-               </recipientheaders>
-               <secretheaders>
-               ...
-               </secretheaders>
-               <customhash>
-                  <name>From</name>
-                  <name>To</name>
-                  <name>Subject</name>
-                  <name>Date</name>
-                  <name>Message-Id</name>
-               </customhash>
-            </mailfile>
-</code>
-Die vereinfachte Checksumme bildet die interne Id der archivierten E-Mail und dient zur Duplikatserkennung.  Zusätzlich wird hier noch die komplette Checksumme der E-Mail gespeichert.
 ===== Ein Beispiel =====
@@ Zeile 72: / Zeile 49: @@
 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).
+⚠️ Hinweis zur Einordnung: Die vereinfachte Checksumme unterscheidet sich rechtlich von der bereits oben beschriebenen Konfiguration über //[[konfiguration#secretheaders|<secretheaders />]]//. Dort werden lediglich Header ausgeschlossen, die eine einzelne, deterministische Importschnittstelle selbst hinzufügt – jedes eingehende Exemplar wird dabei weiterhin vollständig archiviert. Bei der vereinfachten Duplikatserkennung dagegen werden mehrere tatsächlich unterschiedlich zugestellte Mail-Exemplare zusammengeführt, so dass nur eines davon überhaupt ins Archiv gelangt. Diese beiden Fälle sind rechtlich nicht gleich zu bewerten (siehe Abschnitt "Eine Sicht auf rechtliche Aspekte dieser Situation").
 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.
@@ Zeile 77: / Zeile 56: @@
 ====== 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.
+Laut GoBD muss jede im Unternehmen eingegangene elektronische Unterlage in der Form aufbewahrt werden, in der sie zugegangen ist, und darf vor Ablauf der Aufbewahrungsfrist nicht gelöscht werden (GoBD Rz. 119). Jede Mail muss zudem hinsichtlich etwaiger Manipulationen prüfbar sein – Grundsatz der Unveränderbarkeit, GoBD Rz. 108 und Rz. 110 i. V. m. § 146 Abs. 4 AO und § 239 Abs. 3 HGB –, 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?
@@ Zeile 83: / Zeile 62: @@
 ====== 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.
+Nach GoBD Rz. 119 sind im Unternehmen eingegangene elektronische Unterlagen in der Form aufzubewahren, in der sie zugegangen sind, und dürfen vor Fristablauf nicht gelöscht werden. Ob jedes der technisch unterschiedlichen Mail-Exemplare M1, M2, M3 als eigenständige "eingegangene elektronische Unterlage" in diesem Sinne gilt, ist durch den Wortlaut der GoBD nicht eindeutig geklärt. Dies ist eine Auslegungsfrage.
+Dafür spricht, dass sich die Exemplare formell und technisch anhand unterschiedlicher Checksummen unterscheiden lassen und der Grundsatz der Unveränderbarkeit (Rz. 108, Rz. 110) an das jeweilige konkrete Exemplar anknüpft. Dagegen lässt sich anführen, dass die Mehrfachzustellung ausschließlich durch die eigene Hosting-Infrastruktur des Betreibers verursacht wird und inhaltlich dieselbe Geschäftskorrespondenz betrifft. Aus Gründen der rechtlichen Sicherheit empfehlen wir daher weiterhin, im Regelfall alle Exemplare der betreffenden E-Mail (M1, M2, M3 usw.) zu archivieren. Eine Prüfung durch den jeweiligen Rechtsbeistand wird empfohlen.
 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.
+Unabhängig von der GoBD-Bewertung ist zu beachten: Mit der Verwerfung von M2 und M3 gehen auch deren abweichende Transport- und Envelope-Header (u. a. Received-Zeilen, DKIM-Ergebnisse) unwiederbringlich verloren. Diese können im Streit- oder Betriebsprüfungsfall als Nachweis über den konkreten Zustellweg und -zeitpunkt relevant sein. Dieser Beweiswert-Gesichtspunkt sollte bei der Entscheidung des Betreibers eigenständig berücksichtigt werden, auch wenn er über die reine GoBD-Prüfung hinausgeht.
 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.
+Wir gehen bis auf weiteres davon aus, dass es rechtlich vertretbar sein //könnte//, die vereinfachte Doubletten- bzw. Duplikats-Erkennung anzuwenden und damit nur eines von mehrfach anlandenden E-Mail-Exemplaren zu archivieren. Dies ist eine Auslegungsfrage. Voraussetzung dafür ist, dass der Sachverhalt und die dafür maßgeblichen Gründe nachvollziehbar in der gemäß GoBD Rz. 151–155 obligatorischen Verfahrensdokumentation niedergelegt werden. Diese Einschätzung ersetzt keine anwaltliche Prüfung im Einzelfall und ist neu zu bewerten, sobald sich GoBD, Rechtsprechung oder Verwaltungsauffassung zu diesem Punkt ändern.
 Die Entscheidung über die Art der angewendeten Doubletten-Erkennung und damit verbunden die Verantwortung gegenüber der Finanzverwaltung obliegt **einzig und allein** dem Betreiber.
+Rechtsstand dieser Einschätzung:
+. September 2026. Die zugrunde liegenden GoBD-Randziffern wurden am Primärtext (BMF-Schreiben vom 28.11.2019, geändert 11.03.2024 und 14.07.2025) geprüft. Spätere Änderungen der GoBD, der Rechtsprechung oder der Verwaltungsauffassung sind hierin nicht berücksichtigt.
 === 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.

Das Benno MailArchiv Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge