E-maildatum wijzigen: wat kan?

De vraag die iedereen stelt (en waarom ze twee heel verschillende situaties verbergt)

Typ "datum van een ontvangen e-mail wijzigen" in Google. U vindt tientallen threads op Microsoft Q&A-forums, Reddit-discussies, Quora-vragen. De zoekopdracht is duidelijk, maar de redenen erachter zijn radicaal verschillend per persoon.

Er zijn mensen die een datum achteraf willen vervalsen, om redenen die we liever niet bedenken. En er zijn IT-beheerders die na een IMAP-migratie zien dat alle e-mails dezelfde datum tonen (die van de migratie), en gewoon de echte datums terug willen. Die twee situaties hebben niets met elkaar te maken, maar ze delen dezelfde zoekterm.

Dit artikel geeft antwoord op beide vragen. Spoiler: in het eerste geval is wijziging niet op een ondetecteerbare manier mogelijk. In het tweede geval is het volkomen legitiem, en dat is precies wat Redate.io doet.

Eerst: wat is eigenlijk "de datum" van een e-mail?

Een e-mail bevat niet één datum. Er zijn er meerdere, opgeslagen op verschillende plaatsen, beheerd door verschillende partijen.

De Date:-header (RFC 2822)

Dit is de datum die het e-mailprogramma van de afzender in het bericht schrijft op het moment van verzending. In de ruwe headers ziet dat er zo uit:

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

Deze header maakt deel uit van de berichttekst. Technisch gezien kan die worden gewijzigd als u toegang hebt tot het ruwe bestand. Maar "technisch gezien" is hier het sleutelwoord.

De Received:-headers

Elke mailserver waar een e-mail doorheen gaat, voegt zijn eigen Received:-header toe met een tijdstempel. Die headers vormen een chronologische keten, van de server van de afzender tot aan uw postvak. (Als u ooit de ruwe headers van een e-mail hebt geprobeerd te lezen, weet u dat het geen lichte kost is. Tientallen regels technische metadata, in een volgorde die van nieuwste naar oudste loopt.)

De IMAP INTERNALDATE

Dit is de belangrijkste metadata om te begrijpen waarom bepaalde wijzigingen geen zichtbaar effect hebben. De INTERNALDATE is een attribuut dat aan de kant van de IMAP-server wordt opgeslagen, los van de inhoud van het bericht. Dit is wat de meeste e-mailclients gebruiken om berichten in mappen te sorteren. Outlook gebruikt het. Gmail ook. Apple Mail in de meeste gevallen eveneens.

De INTERNALDATE zit niet in het bericht zelf. Die staat in de database van de server. U kunt die niet wijzigen door een .eml-bestand op uw schijf te bewerken.

Wat er werkelijk gebeurt als u lokaal wijzigt

Een .eml-bestand bewerken

Technisch gezien is een .eml-bestand een tekstbestand. U kunt het openen in een editor, de regel Date: aanpassen en opslaan. Als u dat bestand opnieuw importeert in een lokale e-mailclient, kan de weergegeven datum veranderen, afhankelijk van de client.

Maar dit verandert het volgende niet:

De INTERNALDATE op de IMAP-server (blijft ongewijzigd)
De Received:-headers die door tussenliggende servers zijn toegevoegd
De bezorgingslogs bij Google, Microsoft of uw provider
De DKIM-handtekening, als het bericht die had

Resultaat: op uw lokale machine ziet u misschien een andere datum. Vanuit Outlook verbonden met Exchange Online, of Gmail in een browser, is er niets veranderd.

De systeemklok aanpassen

Sommige forums stellen voor om de klok van de werkplek te wijzigen om de e-mailclient te "misleiden". Dat werkt niet. Outlook en Gmail lezen de systeemtijd niet om de datums van ontvangen e-mails te tonen. Ze lezen de INTERNALDATE van de server, of de headers van het bericht. De lokale klok speelt nergens een rol in dat proces.

Manipulatie via Thunderbird

Thunderbird biedt meer flexibiliteit dan de meeste clients. Met extensies of door het profiel rechtstreeks te bewerken (mbox-bestanden, .msf-bestanden) proberen sommigen de datumweergave aan te passen. Dat kan werken binnen Thunderbird zelf, voor e-mails die lokaal zijn opgeslagen in POP3-modus. Maar zodra Thunderbird via IMAP is verbonden, synchroniseert het opnieuw met de server. De "correctie" verdwijnt bij de volgende synchronisatie.

DKIM: de onzichtbare barrière die niemand noemt

De meeste e-mails die sinds 2018 zijn verzonden, zijn ondertekend met DKIM (DomainKeys Identified Mail). Een DKIM-handtekening ziet er in de headers zo uit:

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

Het veld h= vermeldt de headers die door de handtekening worden gedekt. In het bovenstaande voorbeeld is Date ondertekend. Als u de Date:-header van het bericht wijzigt, mislukt de DKIM-verificatie. Elke mailserver en elk forensisch analysetool kan de wijziging detecteren door de handtekening opnieuw te berekenen.

Het is geen perfecte beveiliging (een kwaadwillende afzender beheert zijn eigen DKIM-sleutel en kan op het moment van verzending ondertekenen wat hij wil). Maar voor een e-mail die al ontvangen en ondertekend is, laat het wijzigen van de Date:-header een detecteerbaar spoor achter.

Serverlogs: de echte bron van waarheid

Zelfs als u erin zou slagen alle zichtbare metadata van een e-mail te wijzigen (headers, INTERNALDATE, alles), bewaren providers hun eigen logs.

Google Workspace registreert elk bericht in de auditlogs van de Admin Console. Microsoft 365 doet hetzelfde in het Compliance Center (Purview). Die logs bevatten de bezorgingstijdstempels, ongeacht wat er in de clients wordt weergegeven. Een advocaat, een juridische afdeling of een IT-beveiligingsteam kan die gegevens opvragen. De datum die in Outlook staat, telt niet voor een rechtbank of een beveiligingsaudit.

Voor de duidelijkheid: zelfs een beheerder met toegang tot een postvak via domeinbeheerdersdelegatie kan die logs niet achteraf herschrijven. Ze vallen buiten het bereik van gebruikers, ook bevoorrechte gebruikers.

Het legitieme geval: correctie na migratie

U hebt net een migratie van 150 postvakken van een on-premises Exchange naar Microsoft 365 afgerond. De maandag daarna stromen de tickets binnen: "al mijn oude e-mails hebben de datum van afgelopen vrijdag". De datum van de migratie.

Dit is een goed gedocumenteerd probleem dat volledig verschilt van wat hierboven is beschreven. Hier probeert niemand iets te vervalsen. De echte originele datums bestaan nog steeds, ongewijzigd, in de Date:-header van elk bericht. Het probleem ligt elders: de migratietool (BitTitan MigrationWiz, CloudM, imapsync of een andere) heeft een Received:-header met de migratiedatum bovenaan de keten ingevoegd. Outlook, dat in bepaalde contexten afgaat op de meest recente Received:-headers in plaats van op de INTERNALDATE, toont dan die datum.

In dit geval bestaat de "correctie" uit het herstellen van de samenhang tussen wat het bericht zegt (de originele Date:-header, die er nog steeds is) en wat de server denkt (de INTERNALDATE, die is vastgesteld op het moment van de migratie). Dat is geen vervalsing. Dat is herstel.

Dat is precies het probleem dat uitgebreid wordt beschreven in waarom e-mails de verkeerde datum tonen na migratie. En dat is wat Redate.io oplost.

Waarom zelf doen op grote schaal mislukt

Het probleem begrijpen is één ding. Het corrigeren van 40.000 e-mails verspreid over 150 postvakken zonder er één te verliezen, is een heel ander verhaal.

Scripts die u op GitHub of Stack Overflow vindt, werken op 20 teste-mails. In productie lopen ze vast om redenen die de auteur niet had voorzien:

E-mails die zijn ondertekend met S/MIME of versleuteld met PGP hebben structuren die niet op dezelfde manier te bewerken zijn als gewone berichten
Multipart-berichten met niet-standaard MIME-grenzen veroorzaken parsingsfouten
Headers die zijn gecodeerd volgens RFC 2047 (niet-ASCII-tekens in From:- of Subject:-velden) breken naïeve parsers
De API's van Google en Microsoft kennen rate limiting: om 3 uur 's nachts tijdens een batch van 30.000 e-mails wordt de fout 429 Too Many Requests niet afgehandeld, stopt het script, en weet niemand waar het is gestopt
Geen rollback-mechanisme: als een bericht tijdens de verwerking beschadigd raakt, is er geen weg terug

Redate.io bewaart een kopie van elk origineel bericht in een zichtbare back-upmap gedurende 30 dagen. Elke correctie wordt afzonderlijk geverifieerd. De analysepipeline verwerkt honderden handtekeningen van bekende migratietools, inclusief alle randgevallen die een zelfgemaakt script niet aankan.

Voor meer details per migratietool: BitTitan MigrationWiz en e-maildatums, of CloudM Migrate: verkeerde e-maildatums herstellen.

Wat verandert en wat nooit verandert

Actie	Weergave lokale client	INTERNALDATE server	Providerlogs	DKIM-verificatie
Een .eml-bestand bewerken	Soms gewijzigd	Ongewijzigd	Ongewijzigd	Ongeldig als Date: is ondertekend
Systeemklok aanpassen	Geen effect	Ongewijzigd	Ongewijzigd	Ongewijzigd
Thunderbird-manipulatie (IMAP)	Tijdelijk gewijzigd	Ongewijzigd	Ongewijzigd	Ongewijzigd
Redate.io-correctie (na migratie)	Gecorrigeerd	Gecorrigeerd	Ongewijzigd	Behouden

Het onderscheid is helder. De eerste drie rijen beschrijven oppervlakkige of detecteerbare wijzigingen. De laatste beschrijft een legitieme metadatacorrectie, afgestemd op de originele inhoud van het bericht, na een migratie die een inconsistentie heeft veroorzaakt.

Als u zich in de situatie van de laatste rij bevindt, na een migratie met imapsync, BitTitan, CloudM of een andere tool, dan is Redate.io daar precies voor gemaakt.

Tonen uw e-mails de migratiedatum in plaats van de echte datums? Scan uw postvakken gratis met Redate.io en zie precies hoeveel e-mails worden getroffen voordat u een beslissing neemt.

De datum van een ontvangen e-mail wijzigen: wat kan en wat niet?