Was genau ist eigentlich eine E-Mail?

Vielleicht denken Sie auf den ersten Blick „Was soll denn diese Frage? Was eine E-Mail ist, ist doch ganz klar!“. Was aus typischer Anwendersicht zunächst sicherlich einfach, richtig und nachvollziehbar zu beantworten ist, kann unter eher technischen (und auch Compliance-)Gesichtspunkten jedoch zu einer diffizilen Frage werden. Besonders, wenn es um die Archivierung von E-Mails und die Frage des Originals einer E-Mail geht. Die Finanzverwaltung prüft die E-Mail-Archivierung des Steuerpflichtigen u.a. auf Basis der Ordnungsmäßigkeitskriterien der GoBD, nach der die Wiederherstellung des Originals jeder archivierter E-Mail möglich sein muss.

Selbstverständlich verfügt Benno MailArchiv seit der ersten Stunde über die Möglichkeit, jede archivierte Mail im Original anzuzeigen. Dabei wird die im nativen RFC 822-Format archivierte E-Mail aus dem Archiv geholt, entpackt und als „Quellcode“ dargestellt. Weder ist dies etwas Besonderes, noch erklärt das unsere eingangs gestellte Frage. Archiviert wird schließlich, was vom Mailserver bzw. dem Anwenderpostfach kommt und zu archivieren ist.

Originale und Mail-Exemplare

Was aber passiert, wenn es statt eines einzigen relevanten Originals einer E-Mail ggf. zwei, drei oder gar noch mehr Exemplare gibt? Wir reden hier allerdings audrücklich nicht von einfachen Duplikaten, also bspw. mehrfach abgerufenen E-Mails eines Postfachs oder ähnliches. E-Mail-Duplikate (bzw. Doubletten) zu erkennen, ist eine der elementarsten Aufgaben einer E-Mail-Archivierungslösung. Benno MailArchiv beherrscht dies ebenso lange, wie das Anzeigen von E-Mails im Original.

„Mehrere relevante Originale von ein und derselben E-Mail? Unmöglich!“ sagen Sie? Nicht in komplexen Umgebungen, wie sie bei großen Hostingunternehmen und Cloud Service Providern (CSPs) in der Praxis z.T. immer wieder auftauchen. Hier gelangen E-Mails durch infrastruktur-bedingte Umstände zum Teil mehrfach in den „Verarbeitungstrichter“ von Benno MailArchiv.

Die im Folgenden beschriebenen Sachverhalte sind aus technischer Sicht relativ einfach nachvollziehbar. Aber die gesetzeskonforme E-Mail-Archivierung ist weitaus mehr als das technische Abbilden oder Umsetzen von (GoBD- und Compliance-)Anforderungen. Es ist eine IT-Lösung im Spannungsfeld von Anwenderbelangen, rechtlichen Anforderungen sowie ggf. allgemeinen Complianceanforderungen.

Wir laden Sie hiermit ein, mit uns zu diskutieren, was eine E-Mail ist (oder vielleicht auch nicht ist). Möglicherweise wird sich Ihr Bild über ein so triviales „Ding“ wie E-Mails ändern, wenn Sie diesen Artikel gelesen haben. Schreiben Sie uns eine E-Mail oder nutzen Sie die Kommentarfunktion am Ende dieses Beitrags, um uns Ihre Meinung dazu zu schildern.

E-Mails zu archivieren, ist aus technischer Sicht ein gemeinhin relativ einfaches Unterfangen. Es gibt (grob umrissen) Anwenderpostfächer, Mailserver und Transportwege. Das Ganze ist mit entsprechenden Schnittstellen ausgestattet. Aus den jeweiligen lokalen Gegebenheiten ergeben sich häufig sogar mehrere Möglichkeiten, E-Mails in (den einschlägigen Anforderungen angemessener Art und Weise) zu archivieren.

E-Mail-Archivierung on premise bzw. im eigenen Haus

Eine im on premise Betrieb eingerichtete E-Mail-Archivierung ist dabei häufig dadurch gekennzeichnet, dass alle zu archivierenden E-Mails immer und ausnahmslos über den gleichen Weg bzw. den gleichen gewählten Mechanismus archiviert werden. Mag die E-Mail-Zuführung zum Archiv je nach Kunde und dessen IT-Umgebung individuell sein, so ist festzustellen, dass der Weg aller E-Mails bei on premise Installationen (ist er erst einmal festgelegt und eingerichtet) de facto immer der gleiche ist. Hat man also die Anbindung an das Mailarchiv einmal fertiggestellt, läuft alles weitere quasi wie von selbst. Alle zu archivierenden E-Mails nehmen immer den gleichen Weg. One size fits all.

Der Vorteil dieser Situation ist die Uniformität. Die Mailzuführung zum Archiv erfolgt nach einem fest definierten Schema. Ausnahmen davon gibt es i.d.R. nicht. E-Mail-Duplikate sind somit weitgehend ausgeschlossen. Den Rest, also das Aussortieren etwaiger tatsächlicher Doubletten, übernimmt die Duplikatserkennung von Benno MailArchiv im Augenblick der Archivierung.

E-Mail-Archivierung in der Cloud

Ein ganz anderes Bild zeigt sich häufig jedoch in großen und komplexen Umgebungen. So bspw. insbes. in den Infrastrukturen größerer Hosting- und Cloud-Anbieter. Bedingt durch eine Vielzahl möglicher Umstände (verschiedene Mail-Transportwege, unterschiedliche Mail-Transportserver (MTAs) und unterschiedliche Zuleitungsstrategien zum Archiv (aktiv per SMTP oder passiv durch IMAP oder POP3 u.v.m.)) kommt es hier immer wieder vor, dass die gleiche E-Mail über verschiedene Wege mehrfach zum Archiv transportiert wird und so mehrfach zur Archivierung ansteht.

Insbes. unterschiedliche Mail-Transportwege und MTAs bewirken, dass die transportierten E-Mails je nach durchlaufenem Transportweg mit wege-spezifischen Transportheadern versehen werden. Gelangt eine konkrete E-Mail über unterschiedliche Wege mehrfach zum Archiv, und wird sie dabei mit jeweils unterschiedlichen Headern versehen (was bei unterschiedlichen MTAs unausweichlich ist), werden aus Sicht der Duplikatserkennung unterschiedliche E-Mails zur Archivierung angeliefert.

Schauen wir uns dies an Hand eines Beispiels genauer an:

In einer komplexen Infrastruktur wird eine konkrete E-Mail „M“ über drei unterschiedliche Wege zum Archivieren an Benno MailArchiv übergeben. Durch den Transport eines jeden der drei Exemplare dieser E-Mail (M1, M2, M3) über jeweils unterschiedliche Wege werden je Mail-Exemplar entsprechend unterschiedliche Header eingetragen. Die Mail-Exemplare sind inhaltlich, also aus der nachrichtlichen oder textlichen Sicht des Anwenders betrachtet, identisch. Nichtsdestoweniger unterscheiden sie sich formell sowie technisch durch die unterschiedlichen Header eindeutig von einander.

Die Header machen den Unterschied

Aus der Sicht der Doubletten- bzw. Duplikats-Erkennung von Benno MailArchiv handelt es sich bei den drei Mail-Exemplaren M1, M2 und M3 damit zweifelsfrei um unterschiedliche E-Mails. Bei der Archivierung wird über jede eingelieferte E-Mail eine SHA256-Checksumme erzeugt. Auf Grund der unterschiedlichen Header (der ansonsten identischen Mail-Exemplare) ergeben sich zwangsläufig drei unterschiedliche Checksummen „C1“, „C2“ und „C3“ für die verschiedenen Exemplare. Somit sind die drei Exemplare der gleichen Mail aus Sicht von Benno MailArchiv unterschiedliche E-Mails. Sie würden damit auch als solche jeweils einzeln archiviert werden. Das wiederum hätte zur Konsequenz, dass es aus Anwendersicht (also auf den rein nachrichtlichen Inhalt der E-Mail bezogen) so aussieht, als wären drei gleiche E-Mails im Archiv enthalten. Bei einer Suche über den Nachrichteninhalt würden nämlich alle drei Mail-Exemplare gefunden und angezeigt.

In einem solchen Umfeld ist die herkömmliche Duplikatserkennung nicht sinnvoll. Wer will schon mehrere (dem nachrichtlichen Inhalt nach) gleiche Mails beim Suchen finden? Und wie kann erreicht werden, dass nur eines der drei Mail-Exemplare archiviert wird?

Komplexität erfordert einfache Lösungen

Bekanntermaßen wird Komplexität am ehesten durch innere Einfachheit und einfache Lösungen kompensiert, als durch komplexe Lösungskonstrukte.

Gehen wir den Dingen nun weiter auf den Grund, stellen wir fest, dass eine E-Mail bereits durch die nachstehenden Header und zusätzlich durch ihren Nachrichtentext eindeutig identifizierbar ist:

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

Natürlich ergeben sich insbes. beim Transport per SMTP weitere spezifische Header (sog. Received-Header) in derE-Mail. Die Inhalte dieser Received-Header sind abhängig vom tatsächlichen Transportweg der jeweiligen E-Mail. Das bedeutet, wenn zwei E-Mails M1 und M2 in Bezug auf die vorgenannten (nicht-transportspezifischen) Header identisch sind, handelt es sich definitiv um die gleiche E-Mail – unabhängig davon, welche und wieviele transportbedingte Header noch in der E-Mail enthalten sind.

Conclusio: Der Transportweg verursacht u.U. zusätzliche Header. Dadurch wird eine E-Mail zu einer E-Mail mit mehreren nicht identischen Exemplaren. Die transportbedingten Header sind für die nachrichtliche oder inhaltliche Eindeutigkeit der E-Mail nicht von Bedeutung (ihr Vorhandensein dokumentiert lediglich den durchlaufenen Transportweg).

Außerdem haben nicht nur die Received-Header, auch DKIM-Signaturen (und weitere Elemente) nicht unmittelbar mit dem Inhalt der E-Mail zu tun. Man kann diese Header dem Envelope einer E-Mail zurechnen.

Damit liegt die Lösung für die Situation mit mehreren Mail-Exemplaren, die technisch unterschiedlich, inhaltlich jedoch identisch sind, nahe: Während aus Gründen der Compliance die Prüfsumme über die gesamte E-Mail obligatorisch ist, löst eine zweite Checksumme, die ausschließlich auf den oben genannten E-Mail-Bestandteilen basiert, das Dilemma ebenso einfach, wie wirkungsvoll.

Praxis versus Formalkriterien und Compliance

Manches Thema kann auf technischem Wege elegant gelöst werden. Indes scheitert manche praktische Lösung im Alltag an schnöden Formalaspekten. So ist es auch hier angebracht, etwas genauer hinzusehen, denn Compliance geht bzgl. E-Mail-Archivierung leider vor Praktikabilität:

Die GoBD-konforme E-Mail-Archivierung bedarf der Möglichkeit, jede E-Mail in ihrem Originalzustand aus dem Archiv wiederherstellen zu können. Jede E-Mail muss also incl. aller Header, Attachments usw., also quasi im „Nachrichtenquelltext“, angezeigt werden können. Außerdem muss jede E-Mail in Bezug auf etwaige Manipulationen prüfbar sein. Konkret kann anhand der oben erwähnten Checksumme über die gesamte E-Mail die Konsistenz bzw. Unverletztheit einer archivierten E-Mail sowie des gesamten Archivinhalts überprüft werden.

Kommen wir damit zurück zu unserem Beispiel: Werden nun mehrere textlich bzw. inhaltlich gleiche E-Mails M1, M2 und M3 (im oben genannten Sinne unterschiedlicher Exemplare der gleichen E-Mail) der Archivierung zugeführt, stellt sich die Frage, wie nun mit den hinsichtlich ihrer Header unterschiedlichen Mail-Exemplaren verfahren werden sollte.

Eine Sicht auf rechtliche Aspekte dieser Situation

Wir gehen davon aus, dass rein rechtlich gesehen kein Zwang besteht, dass mehrere Varianten einer E-Mail archiviert werden müssen, insbes. dann, wenn sie sich nur in Bezug auf die enthaltenen Mailheader voneinander unterscheiden. Da jedoch nicht auszuschließen ist, dass verschiedene Kreise unterschiedliche Rechtsauffassungen vertreten, ist es möglich, dass unsere Annahme nicht auf ungeteilte Zustimmung stößt oder rechtlich gesehen gar falsch ist.

Um ein mögliches (rechtliches) Dilemma auszuschließen, sollten daher (pragmatisch betrachtet) alle Exemplare der betreffenden E-Mail (in unserem Beispiel M1, M2, M3) archiviert werden.

Betrachtet man die Sachlage rein formell, handelt es sich bei mehreren Mail-Exemplaren im Sinne unseres Beispiels um unterschiedliche E-Mails. Auch wenn die Unterschiede zwischen ihnen technischer Natur sind und der praktische Nutzwert der Differenzen zwischen ihnen im Alltag nicht oder kaum vorhanden ist, handelt es sich formell um unterschiedliche E-Mails. Dies kann sofort anhand der unterschiedlichen Checksummen nachvollzogen werden.

Jegliche Rechtsunsicherheit kann andererseits einfach dadurch ausgeschlossen werden, dass alle Mail-Exemplare archiviert werden. Auch wenn es technisch anhand des oben beschriebenen Verfahrens mit zwei unterschiedlichen Checksummen je E-Mail leicht realiserbar wäre, z.B. nur das erste Exemplar einer Reihe von Mail-Exemplaren zu archivieren

Um hier eine für den Betreiber rechtssichere Lösung zu erreichen, raten wir dazu, diesen Sachverhalt vor der Umsetzung mit einem Rechtsbeistand der Wahl zu erörtern. Erst wenn über die konkrete Form der Umsetzung der Doubletten-Erkennung beraten und entschieden wurde, sollte die Implementierung dementsprechend umgesetzt werden.

Bis auf weiteres gehen wir davon aus, dass es rechtlich ausreichend sein könnte, die vereinfachte Doubletten- bzw. Duplikats-Erkennung anzuwenden, also nur eines von mehrfach anlandenden E-Mail-Exemplaren zu archivieren. Auf Grund der Anforderungen der GoBD steht die Erstellung einer Verfahrensdokumentation außer jeder Frage und ist obligatorisch. Wir gehen in diesem Zusammenhang davon aus, dass die Erklärung bzw. Niederschrift des Sachverhalts, dass nur ein Mail-Exemplar archiviert wird, in der 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.

Was ist eine E-Mail?

Ist eine E-Mail nun jedes Exemplar, auch wenn sich zwei Exemplare nur durch einen einzigen Transportheader unterscheiden, der seinerseits nicht zur Erhöhung des Informationswertes der Nachricht beiträgt? Ist eine E-Mail damit also rein nach den Formalkriterien zu klassifizieren? Oder ist eine E-Mail eine Nachricht zwischen zwei oder mehr Anwendern, deren essentieller (und auch für die GoBD-konforme Archivierung  relevanter) Teil die eigentliche Nachricht ist? Sind die (für den Anwender i.d.R. ohnehin im Verborgenen bleibenden) Mailheader auch in Bezug auf die GoBD in ihrer Relevanz gar nicht so wichtig (auch wenn sie als Teil der Originalmail archiviert werden)?

Was eine E-Mail letztlich genau ist, bleibt in diesem Sinne wohl noch eine Zeit lang weiter offen.

Nun haben Sie, lieber Leser, das Wort! Schreiben Sie uns eine Mail oder einen Kommentar, wie Ihre Auffassung über die Art und den Umfang einer E-Mail ist.

Rechtlicher Hinweis / Haftungsauschluss / Disclaimer

Dieser Beitrag 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.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.