E-Mail-Datum ändern: Was wirklich möglich ist

Die Frage, die alle stellen (und warum sie zwei völlig verschiedene Situationen verbirgt)

Geben Sie "empfangene E-Mail Datum ändern" in Google ein. Sie finden Dutzende von Threads in Microsoft Q&A-Foren, Reddit-Diskussionen, Quora-Fragen. Die Anfrage ist klar, aber die Gründe dahinter sind je nach Person grundverschieden.

Da sind die, die ein Datum rückwirkend fälschen wollen, aus Gründen, über die man lieber nicht nachdenkt. Und dann gibt es IT-Administratoren, die nach einer IMAP-Migration sehen, wie alle ihre E-Mails dasselbe Datum tragen (das der Migration), und einfach die echten Daten wiederherstellen möchten. Diese beiden Situationen haben nichts miteinander zu tun, werden aber mit derselben Suchanfrage formuliert.

Dieser Artikel beantwortet beide Fragen. Spoiler: Im ersten Fall ist eine Änderung nicht wirklich unentdeckbar möglich. Im zweiten ist sie völlig legitim, und genau das macht Redate.io.

Zunächst: Was ist eigentlich das "Datum" einer E-Mail?

Eine E-Mail enthält nicht ein einziges Datum. Sie enthält mehrere, an verschiedenen Stellen gespeichert, kontrolliert von verschiedenen Instanzen.

Der Date:-Header (RFC 2822)

Das ist das Datum, das das E-Mail-Programm des Absenders beim Senden in die Nachricht schreibt. In den Roh-Headern sieht es so aus:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Dieser Header ist Teil des Nachrichtentexts. Technisch gesehen kann er geändert werden, wenn Sie auf die Rohdatei zugreifen. Aber "technisch" ist hier das entscheidende Wort.

Die Received:-Header

Jeder Mailserver, über den eine E-Mail läuft, fügt seinen eigenen Received:-Header mit einem Zeitstempel ein. Diese Header bilden eine chronologische Kette, vom Server des Absenders bis zu Ihrem Postfach. (Wer schon einmal versucht hat, die Roh-Header einer E-Mail zu lesen, weiß: Das ist nicht gerade Urlaubslektüre. Dutzende Zeilen technischer Metadaten, in einer Reihenfolge, die vom Neuesten zum Ältesten läuft.)

Das IMAP INTERNALDATE

Das ist die wichtigste Metadaten, um zu verstehen, warum manche Änderungen keinerlei sichtbare Wirkung haben. Das INTERNALDATE ist ein serverseitig gespeichertes Attribut des IMAP-Protokolls, unabhängig vom Inhalt der Nachricht. Die meisten E-Mail-Clients nutzen es zum Sortieren der E-Mails in den Ordnern. Outlook tut es. Gmail auch. Apple Mail in den meisten Fällen ebenfalls.

Das INTERNALDATE steckt nicht in der Nachricht. Es steckt in der Datenbank des Servers. Sie können es nicht ändern, indem Sie eine .eml-Datei auf Ihrer Festplatte bearbeiten.

Was wirklich passiert, wenn Sie lokal ändern

Eine .eml-Datei bearbeiten

Technisch gesehen ist eine .eml-Datei eine Textdatei. Sie können sie in einem Editor öffnen, die Date:-Zeile ändern, speichern. Wenn Sie diese Datei in einen lokalen E-Mail-Client reimportieren, kann sich das angezeigte Datum je nach Client ändern.

Aber hier ist, was sich dabei nicht ändert:

• Das INTERNALDATE auf dem IMAP-Server (bleibt unberührt)
• Die Received:-Header der Zwischenserver
• Die Zustellungslogs bei Google, Microsoft oder Ihrem Provider
• Die DKIM-Signatur, falls die Nachricht eine hatte

Ergebnis: Auf Ihrem lokalen Rechner sehen Sie vielleicht ein anderes Datum. In Outlook, das mit Exchange Online verbunden ist, oder in Gmail im Browser hat sich nichts geändert.

Die Systemuhr ändern

Manche Foren empfehlen, die Uhr des Arbeitsrechners zu verstellen, um den E-Mail-Client zu "täuschen". Das funktioniert nicht. Outlook und Gmail lesen nicht die Systemzeit, um Datumsangaben empfangener E-Mails anzuzeigen. Sie lesen das INTERNALDATE vom Server oder die Header der Nachricht. Die lokale Uhr spielt in diesem Prozess nirgendwo eine Rolle.

Manipulation über Thunderbird

Thunderbird bietet mehr Flexibilität als die meisten Clients. Mit Erweiterungen oder durch direkte Bearbeitung des Profils (mbox-Dateien, .msf-Dateien) versuchen manche, die Datumsanzeige zu verändern. Das kann in Thunderbird selbst funktionieren, für lokal im POP3-Modus gespeicherte E-Mails. Aber sobald Thunderbird per IMAP verbunden ist, synchronisiert es mit dem Server. Die "Korrektur" verschwindet bei der nächsten Synchronisation.

DKIM: die unsichtbare Barriere, die niemand erwähnt

Die meisten seit 2018 versendeten E-Mails sind mit DKIM (DomainKeys Identified Mail) signiert. Eine DKIM-Signatur sieht in den Headern so aus:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Das Feld h= listet die von der Signatur abgedeckten Header auf. Im obigen Beispiel ist Date signiert. Wenn Sie den Date:-Header der Nachricht ändern, schlägt die DKIM-Prüfung fehl. Jeder Mailserver, jedes forensische Analysetool kann die Änderung durch Neuberechnung der Signatur erkennen.

Das ist kein perfekter Schutz (ein bösartiger Absender kontrolliert seinen eigenen DKIM-Schlüssel und kann beim Versand signieren, was er will). Aber bei einer bereits empfangenen und signierten E-Mail hinterlässt das Ändern des Date:-Headers eine nachweisbare Spur.

Server-Logs: die eigentliche Quelle der Wahrheit

Selbst wenn es Ihnen gelänge, alle sichtbaren Metadaten einer E-Mail zu ändern (Header, INTERNALDATE, alles), führen die Anbieter ihre eigenen Logs.

Google Workspace protokolliert jede Nachricht in den Audit-Logs der Admin-Konsole. Microsoft 365 tut dasselbe im Compliance-Center (Purview). Diese Logs enthalten die Zustellungszeitstempel, unabhängig davon, was in den Clients angezeigt wird. Ein Anwalt, eine Rechtsabteilung oder ein IT-Sicherheitsteam kann diese Daten abrufen. Das in Outlook angezeigte Datum zählt nicht vor Gericht oder bei einem Sicherheits-Audit. Die DSGVO-Anforderungen und Aufbewahrungspflichten, die dem Finanzamt gegenüber gelten, stützen sich auf diese serverseitigen Protokolle, nicht auf Clientanzeigen.

Genauer gesagt: Selbst ein Administrator mit Delegationszugang zur Mailbox kann diese Logs nicht rückwirkend überschreiben. Sie sind außerhalb der Reichweite von Nutzern, auch privilegierten.

Der legitime Fall: die Korrektur nach einer Migration

Sie haben gerade 150 Postfächer von einem Exchange on-premise zu Microsoft 365 migriert. Am folgenden Montag kommen die Tickets: "Alle meine alten E-Mails sind auf den letzten Freitag datiert". Das Datum der Migration.

Das ist ein gut dokumentiertes Problem, das sich von dem, was wir gerade beschrieben haben, grundlegend unterscheidet. Hier möchte niemand etwas fälschen. Die echten Originaldaten sind noch immer vorhanden, intakt, im Date:-Header jeder Nachricht. Das Problem liegt woanders: Das Migrationstool (BitTitan MigrationWiz, CloudM, imapsync oder ein anderes) hat einen Received:-Header mit dem Migrationsdatum an den Anfang der Kette gesetzt. Outlook, das in bestimmten Kontexten auf die neuesten Received:-Header schaut statt auf das INTERNALDATE, zeigt stattdessen dieses Datum an.

In diesem Fall besteht die "Korrektur" darin, die Konsistenz zwischen dem, was die Nachricht sagt (der originale Date:-Header, noch immer vorhanden), und dem, was der Server denkt (das INTERNALDATE, zum Zeitpunkt der Migration gesetzt), wiederherzustellen. Das ist keine Fälschung. Das ist Wiederherstellung.

Genau das beschreibt dieser Artikel über falsche E-Mail-Daten nach der Migration. Und genau das löst Redate.io.

Warum "selbst machen" in der Praxis scheitert

Das Problem zu verstehen ist eine Sache. Es auf 40.000 E-Mails verteilt auf 150 Postfächer zu korrigieren, ohne eine einzige zu verlieren, ist eine völlig andere.

Die Skripte, die man auf GitHub oder Stack Overflow findet, funktionieren bei 20 Test-E-Mails. In der Produktionsumgebung stoßen sie auf Probleme, die der Skript-Autor nicht vorhergesehen hatte:

• S/MIME-signierte oder PGP-verschlüsselte E-Mails haben Strukturen, die sich nicht wie gewöhnliche Nachrichten bearbeiten lassen
• Multipart-Nachrichten mit nicht standardkonformen MIME-Grenzen verursachen Parsing-Fehler
• Nach RFC 2047 kodierte Header (Nicht-ASCII-Zeichen in From:- oder Subject:-Feldern) bringen naive Parser zum Absturz
• Die Google- und Microsoft-APIs erzwingen Rate Limiting: Um 3 Uhr nachts bei einem Batch von 30.000 E-Mails wird der Fehler 429 Too Many Requests nicht behandelt, das Skript bricht ab, und niemand weiß, wo es gestoppt hat
• Kein Rollback-Mechanismus: Wenn eine Nachricht während der Verarbeitung beschädigt wird, gibt es keinen Weg zurück

Redate.io bewahrt eine Kopie jeder Original-E-Mail in einem sichtbaren Sicherungsordner für 30 Tage auf. Jede Korrektur wird einzeln verifiziert. Die Analyse-Pipeline verarbeitet Hunderte von Signaturen bekannter Migrationstools sowie alle Randfälle, die ein selbst gebautes Skript nicht behandeln würde.

Mehr zu den Besonderheiten je nach verwendetem Tool: BitTitan MigrationWiz und falsche E-Mail-Daten, oder CloudM Migrate: falsche Datumsangaben korrigieren.

Was sich ändert, was sich nie ändert

Der Unterschied ist eindeutig. Die ersten drei Zeilen der Tabelle beschreiben oberflächliche oder erkennbare Änderungen. Die letzte beschreibt eine legitime Metadaten-Korrektur, die mit dem Originalinhalt der Nachricht übereinstimmt, nach einer Migration, die eine Inkonsistenz eingeführt hat.

Wenn Sie sich in der Situation befinden, die in der letzten Tabellenzeile beschrieben wird, nach einer Migration mit imapsync, BitTitan, CloudM oder einem anderen Tool, ist Redate.io dafür gemacht.

Zeigen Ihre E-Mails das Migrationsdatum statt der echten Daten? Scannen Sie Ihre Postfächer kostenlos mit Redate.io und sehen Sie genau, wie viele E-Mails betroffen sind, bevor Sie eine Entscheidung treffen.