E-maildatum aanpassen: mogelijk en detecteerbaar

Een e-maildatum aanpassen: waar hebben we het over?

De vraag duikt regelmatig op in sysadmin-forums en MSP-Slack-groepen: is het mogelijk om de datum van een e-mail te wijzigen nadat die verstuurd is? Het korte antwoord is ja, technisch gezien. Maar het volledige antwoord is een stuk minder geruststellend voor wie dat met kwade bedoelingen zou willen doen.

Een e-mail is geen monolithisch bestand. Het is een verzameling tekstuele headers gevolgd door een berichtinhoud. Meerdere van die headers bevatten datuminformatie. En sommige zijn eenvoudiger te wijzigen dan andere.

Drie dateringslagen bestaan naast elkaar in elke e-mail:

• De Date:-header (RFC 2822), geschreven door de mailclient op het moment van verzending
• De Received:-headers, toegevoegd door elke server die het bericht doorgeeft
• De IMAP INTERNALDATE, een metadataveld dat server-side wordt opgeslagen, los van de berichtinhoud

Al deze lagen zijn aanpasbaar. Geen van alle zonder sporen achter te laten.

De Date:-header wijzigen: de meest voor de hand liggende manipulatie

De Date:-header is platte tekst in het .eml-bestand. Technisch gezien kan elke hex-editor of Python-script die in enkele seconden herschrijven. Als u wel eens de ruwe headers van een e-mail in Gmail hebt bekeken (het kleine menu "Origineel weergeven"), weet u dat dit voor iedereen leesbaar is.

Het probleem? Sinds 2004 ondertekent de grote meerderheid van mailservers uitgaande e-mails met DKIM (DomainKeys Identified Mail). Deze cryptografische handtekening dekt expliciet meerdere headers, waaronder Date:, From:, Subject: en de berichtinhoud. De handtekening wordt opgeslagen in de DKIM-Signature:-header.

De Date: wijzigen nadat die is ondertekend, maakt de DKIM-verificatie mechanisch ongeldig. Elke ontvangende server kan de handtekening controleren door de publieke sleutel op te halen uit de DNS van het verzendende domein. Als de handtekening niet meer klopt, wordt het bericht gemarkeerd als gewijzigd. Gmail, Outlook.com en alle grote providers doen deze verificatie automatisch.

(Als u trouwens een DKIM-handtekening concreet wilt zien: open de ruwe headers van een e-mail ontvangen via Gmail of Office 365. U vindt er een regel DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... die eruitziet als ruis, maar in werkelijkheid een cryptografische hash van het volledige bericht is.)

Kortom: de Date: wijzigen op een DKIM-ondertekende e-mail verbreekt het zegel. De wijziging is zichtbaar voor elke beheerder die weet waar hij moet kijken.

Received:-headers herschrijven: een keten die moeilijk te vervalsen is

De Received:-headers volgen het pad dat een e-mail heeft afgelegd tussen verzender en ontvanger. Elke SMTP-server die het bericht verwerkt, voegt er een toe met zijn naam, IP-adres en een tijdstempel. Een e-mail die via twee of drie relays loopt, bevat dus twee of drie gestapelde Received:-headers.

Kunnen die worden gewijzigd? Technisch, ja, op uw eigen kopie van het bericht. Maar hier zit de val: de ontvanger heeft ook een kopie. En zijn server heeft als laatste zijn eigen Received:-header toegevoegd. Die header valt onder de controle van de ontvanger, niet van de verzender. Hij is onmogelijk van buitenaf te vervalsen.

De coherentie van de keten is controleerbaar. Als de timestamps van opeenvolgende Received:-headers niet kloppen (een tussenliggende relay zou het bericht ontvangen hebben voordat de verzender het verstuurde, bijvoorbeeld) is dat meteen verdacht. Forensische e-mailanalysetools zoals MXToolbox of interne beveiligingstools controleren precies dit.

Eerlijk gezegd klopt het niet helemaal om te zeggen dat Received:-headers volledig onvervalsbaar zijn: een aanvaller die zijn eigen mailinfrastructuur beheert, kan geloofwaardige headers fabriceren voor de relays die hij controleert. Maar hij beheerst nooit de laatste schakel: de server van de ontvanger.

De IMAP INTERNALDATE: het meest technische geval

De INTERNALDATE is een IMAP-metadataveld dat server-side wordt opgeslagen. Het is geen header in het bericht zelf: het is een waarde die de server aan het bericht koppelt in zijn interne database. Dit is de waarde die de meeste mailclients gebruiken om berichten in de inbox te sorteren.

Het IMAP-commando APPEND maakt het mogelijk een bericht op een server te plaatsen met een expliciet opgegeven INTERNALDATE. Dit is een legitieme functie van het protocol, gedocumenteerd in RFC 3501. Migratietools gebruiken dit voortdurend: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... ze plaatsen allemaal e-mails op de doelserver met een opgegeven INTERNALDATE.

Theoretisch zou iemand met IMAP-toegang tot zijn eigen mailbox een e-mail kunnen plaatsen met een willekeurige INTERNALDATE. Maar deze manipulatie wijzigt de berichtheaders niet. De originele Date: blijft intact, de Received:-headers blijven intact, de DKIM-handtekening blijft intact. Alleen de server-side sorteermetadata verandert.

Voor een expert die het ruwe bericht onderzoekt, is de discrepantie tussen de INTERNALDATE en de Date: meteen zichtbaar. En als het bericht DKIM-ondertekend is, wordt de originele datum cryptografisch bevestigd.

De Message-ID: een moeilijk te vervalsen vingerafdruk

Elke e-mail krijgt een unieke identificator, de Message-ID:-header. Die identificator wordt aangemaakt door de verzendende SMTP-server op het moment van verzending, doorgaans door een tijdstempel, een willekeurige identifier en de domeinnaam van de server te combineren.

Een typische Message-ID ziet er zo uit: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Het tijdstempel is vaak direct in de identificator gecodeerd. De datum van het bericht wijzigen terwijl een Message-ID met een incompatibel tijdstempel achterblijft, creëert een direct opvallende inconsistentie.

Bovendien worden Message-IDs geïndexeerd door grote berichtenplatforms. Google, Microsoft en anderen houden logs bij waarmee kan worden nagegaan wanneer een bericht daadwerkelijk op hun infrastructuur heeft gecirculeerd. In een juridische of forensische context zijn deze logs toegankelijk via gerechtelijke procedures.

In de praktijk: wie kan een manipulatiepging detecteren?

Laten we de vraag concreet stellen. U ontvangt een e-mail waarvan u vermoedt dat de datum is gewijzigd. Wat kan een IT-beheerder of een jurist met enige technische bagage doen?

• DKIM-verificatie: in Gmail toont het menu "Origineel weergeven" het DKIM-verificatieresultaat bovenaan de pagina. Een "PASS" bevestigt de integriteit van het bericht sinds verzending. Een "FAIL" of "SOFTFAIL" wijst op een wijziging.
• Headeranalyse: tools zoals MXToolbox Header Analyzer of de Google Admin Toolbox parseren automatisch de Received:-keten en signaleren temporele inconsistenties.
• Coherentie Message-ID / Date: een analist kan het tijdstempel in de Message-ID vergelijken met de waarde van de opgegeven Date:.
• Serverlogs: als de e-mail via een server is gegaan waarvan u beheerder bent, bevatten de SMTP-logs de werkelijke datum en tijd van berichtacceptatie, ongeacht de headers.

De detectietools zijn toegankelijk, gratis en vereisen geen gevorderde forensische kennis. Een nieuwsgierige IT-beheerder kan de integriteit van een e-mail in minder dan twee minuten controleren.

Het enige legitieme geval van massale datumwijziging: IMAP-migratie

Er bestaat een scenario waarbij honderdduizenden e-mails met onjuiste datums eindigen zonder enige kwade opzet: IMAP-migratie.

U hebt net een migratie van 150 Exchange-mailboxen naar Google Workspace afgerond. Maandagochtend stromen de tickets binnen. Gebruikers melden dat al hun oude e-mails dezelfde datum tonen, die van het migratieweekend. Hun inboxen zijn onleesbaar.

Wat er is gebeurd, is gedocumenteerd en voorspelbaar: de migratietool (BitTitan, CloudM, imapsync, maakt niet uit) heeft de e-mails via IMAP APPEND op Google Workspace geplaatst. Daarbij werd een INTERNALDATE opgegeven die overeenkomt met de migratiedatum, niet de originele datum van de e-mail. Resultaat: Outlook, dat standaard op INTERNALDATE sorteert, toont de migratiedatum voor alle berichten. Waarom e-mails de verkeerde datum tonen na migratie legt dit mechanisme gedetailleerd uit.

De originele Date:-header is in elk bericht intact. De DKIM-handtekeningen zijn intact. De inhoud is niet gewijzigd. Alleen de server-side INTERNALDATE is onjuist.

Dit probleem treft BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO en alle tools die IMAP APPEND gebruiken zonder de INTERNALDATE correct te bewaren. Het artikel over BitTitan MigrationWiz behandelt de specifieke kenmerken van die tool. De migratiechecklist somt de punten op die voor en na een migratie gecontroleerd moeten worden om dit soort problemen te voorkomen.

Het verschil tussen corrigeren en vervalsen

De correctie die Redate.io uitvoert, staat lijnrecht tegenover een vervalsingspoging. De eigen correctie-engine analyseert de headerreeks van elk bericht, identificeert de originele datum die is gecodeerd in de Date:-header (RFC 2822) en die nooit is gewijzigd, en corrigeert de datummetadata zodat die overeenkomt met deze authentieke informatie die al in het bericht aanwezig is.

De Date:-header is de bron van waarheid. Die is geschreven door de mailclient van de verzender op het moment van verzending. Die valt onder de DKIM-handtekening. Redate.io wijzigt die niet. Wat wordt gecorrigeerd, is de discrepantie die door de migratietool is geïntroduceerd, niet de originele datum.

47.000 e-mails corrigeren na een mislukte migratie zonder er een te verliezen, zonder gespreksthreads te verbreken, zonder bijlagen te beschadigen, zonder om 3 uur 's nachts een 429-fout op de Google API te veroorzaken: dat is een meerfasige analysepipeline met afhandeling van randgevallen (S/MIME, PGP, niet-ASCII-coderingen in RFC 2047, complexe multipart-structuren). Een Python-script van vijf regels overleeft de eerste productiemailbox niet. Kunnen e-maildatums worden hersteld na migratie legt uit waarom doe-het-zelf riskant is bij echte volumes.

Redate.io scant mailboxen gratis, identificeert e-mails met onjuiste datums en corrigeert via een validatiepipeline die elk bericht afzonderlijk controleert. De originelen worden 30 dagen bewaard in een zichtbare back-upmap. Als er iets misgaat, is terugdraaien mogelijk.

Heeft uw migratie de datums van uw e-mails verschoven? Start een gratis scan op Redate.io om de omvang van het probleem in kaart te brengen voordat u beslist wat u doet.