De drie datums in elke e-mail
Elke e-mail die op een IMAP-server is opgeslagen, draagt minstens drie afzonderlijke datumwaarden. Begrijpen hoe deze datums werken, en hoe e-mailclients kiezen welke ze tonen, is de sleutel tot het begrijpen waarom migratie datums kapotmaakt. Dit artikel is een diepgaande technische analyse van het IMAP-datumsysteem, bedoeld voor IT-beheerders en iedereen die de kernoorzaak van datumproblemen na migratie wil begrijpen.
1. De RFC 2822 "Date"-header
De "Date"-header is gedefinieerd in RFC 2822 (Internet Message Format). Deze wordt ingesteld door de e-mailclient van de afzender op het moment dat het bericht wordt opgesteld en verzonden. Deze header maakt deel uit van het berichtlichaam zelf - hij reist mee met het bericht en wordt nooit gewijzigd door mailservers op het bezorgtraject. Een typische Date-header ziet er als volgt uit:
Date: Mon, 15 Jan 2024 09:32:17 +0100
De Date-header vertegenwoordigt de "verzenddatum" van het bericht. Dit is de meest betrouwbare datum omdat deze eenmalig wordt ingesteld en nooit wordt gewijzigd. De header weerspiegelt echter de klok van de afzender, die verkeerd geconfigureerd kan zijn. In zeldzame gevallen kan de Date-header volledig ontbreken (met name bij geautomatiseerde systeemmeldingen of misvormde berichten).
2. De IMAP INTERNALDATE
De INTERNALDATE is gedefinieerd in RFC 3501 (IMAP4rev1-protocol). Het is een serverzijdige metadatawaarde die de datum en tijd vertegenwoordigt waarop het bericht aan de server is bezorgd. In tegenstelling tot de Date-header maakt de INTERNALDATE geen deel uit van het e-mailbericht zelf. Het wordt apart opgeslagen door de IMAP-server als metadata.
Wanneer een e-mail normaal wordt bezorgd (niet gemigreerd), stelt de IMAP-server de INTERNALDATE in op het huidige tijdstip op het moment van bezorging. Deze waarde komt nauw overeen met de Date-header, doorgaans binnen enkele seconden of minuten. E-mailclients gebruiken de INTERNALDATE vaak als "ontvangstdatum" omdat deze het moment weerspiegelt waarop de server het bericht daadwerkelijk heeft ontvangen.
En hier wordt het interessant. Wanneer een bericht wordt geplaatst via het IMAP APPEND-commando (wat migratietools gebruiken), staat het APPEND-commando toe dat de client de INTERNALDATE expliciet opgeeft. Goed ontworpen migratietools gebruiken deze functie om de oorspronkelijke INTERNALDATE van de bronserver te behouden. Maar zelfs wanneer de INTERNALDATE correct is ingesteld, kan het "Received"-headerprobleem (hieronder beschreven) de weergegeven datum in veel clients alsnog overschrijven.
3. De keten van "Received"-headers
Elke keer dat een e-mail door een mailserver gaat, voegt die server een "Received"-header toe aan het begin van het bericht. Dit creeert een keten van Received-headers die de reis van de e-mail van afzender tot ontvanger vastlegt. De meest recente (bovenaan) toont de laatste server die het bericht heeft verwerkt, en de oudste (onderaan) toont de eerste.
Een normaal e-mailbericht kan 3 tot 6 Received-headers bevatten, die de reis documenteren van de uitgaande server van de afzender via relays naar de inkomende server van de ontvanger. Elke Received-header bevat een tijdstempel. Hier is een vereenvoudigd voorbeeld:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Hoe e-mailclients kiezen welke datum ze tonen
Outlook (Desktop, Web, Mobiel)
Microsoft Outlook gebruikt een combinatie van de INTERNALDATE en de meest recente "Received"-header om de "Ontvangen"-datum te bepalen die in het postvak wordt getoond. In de praktijk geeft Outlook doorgaans de voorkeur aan het tijdstempel van de meest recente Received-header voor de kolom "Ontvangen". De kolom "Verzonden" gebruikt de Date-header. Omdat Outlook standaard op de kolom "Ontvangen" sorteert, is het het Received-headertijdstempel dat gebruikers als eerste zien.
Apple Mail
Apple Mail op macOS en iOS gebruikt voornamelijk de IMAP INTERNALDATE om de datum weer te geven. Als de INTERNALDATE correct is bewaard tijdens migratie, kan Apple Mail de juiste datum tonen, maar alleen als de INTERNALDATE expliciet is ingesteld bij de APPEND-operatie. Als de migratietool de INTERNALDATE niet heeft ingesteld, gebruikt de server standaard het insertietijdstip (de migratiedatum). Zie voor details over de impact voor Apple Mail-gebruikers Apple Mail: verkeerde datum na migratie.
Thunderbird
Mozilla Thunderbird biedt de meeste flexibiliteit. Het kan zowel "Datum" (van de Date-header) als "Ontvangen" (van de Received-headers) tonen. Standaard toont Thunderbird de Date-headerwaarde, wat betekent dat datums correct kunnen lijken in Thunderbird terwijl ze verkeerd zijn in Outlook. De kolom "Ontvangen" in Thunderbird toont altijd de migratiedatum. Zie Thunderbird: verkeerde datum na migratie voor meer details.
Gmail-webinterface
De Gmail-webclient gebruikt de Date-header voor de primaire datumweergave. Dit betekent dat Gmail web vaak correcte datums toont, zelfs na migratie. Maar de IMAP INTERNALDATE op de Gmail-server is alsnog onjuist, wat elke IMAP-client beinvloedt die verbinding maakt met dat Gmail-account. Het verschil tussen Gmail web en Outlook of Apple Mail is een veelvoorkomende bron van verwarring, en een die beheerders veel foutopsporingstijd kost.
Waarom IMAP APPEND datums kapotmaakt
Wat er tijdens migratie gebeurt
Wanneer een migratietool een e-mail verplaatst van Server A naar Server B, maakt de tool verbinding met Server A via IMAP en downloadt het ruwe bericht, maakt vervolgens verbinding met Server B en gebruikt het APPEND-commando om het te plaatsen. Tijdens deze insertie behandelt Server B het inkomende bericht en voegt een nieuwe Received-header toe met het huidige tijdstempel: de migratiedatum. Dit is standaard IMAP-gedrag zoals gedefinieerd in het protocol. De server behandelt elke APPEND als een nieuwe berichtbezorging.
Het resultaat: een gecontamineerde headerketen
Na migratie zien de Received-headers van de e-mail er als volgt uit:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
De Received-header van de migratietool is nu de bovenste vermelding. Elke e-mailclient die de meest recente Received-header gebruikt om de weergavedatum te bepalen (Outlook, met name) toont "11 april 2025" in plaats van "15 januari 2024". De oorspronkelijke Date-header en de oorspronkelijke Received-headers zijn nog steeds intact eronder, maar ze staan niet meer op de positie die e-mailclients prioriteit geven.
Zelfs goede INTERNALDATE-verwerking voorkomt dit niet
Sommige migratietools stellen de INTERNALDATE correct in tijdens APPEND. imapsync bijvoorbeeld behoudt expliciet de INTERNALDATE van de bronserver. Maar de Received-header wordt toegevoegd door de doelserver, niet door de migratietool. De migratietool heeft geen controle over dit gedrag. Zelfs met perfect INTERNALDATE-behoud bevat de bovenste Received-header nog steeds de migratiedatum, en clients zoals Outlook tonen nog steeds de verkeerde datum.
Wat kunt u hier concreet aan doen?
Welke migratietools Received-headers toevoegen
Alle IMAP-migratietools veroorzaken dit probleem omdat de Received-header wordt toegevoegd door de doelserver, niet door de tool zelf. De inhoud van de toegevoegde header verschilt per tool en server.
BitTitan MigrationWiz voegt een Received-header toe die "mx.migrationwiz.com" bevat. CloudM Migrate voegt headers toe die verwijzen naar "cloudm.io". imapsync triggert een generieke Received-header van de doelserver. GSMMO voegt headers toe met verwijzingen naar "gmailapi.google.com".
De correctie: correcte datums herstellen
Het goede nieuws is dat de correcte datuminformatie nog steeds in elke e-mail aanwezig is. De oorspronkelijke Date-header is intact. De oorspronkelijke Received-headers zijn intact. Het probleem is dat een verontreinigde header er bovenop zit.
De eigen correctie-engine van Redate.io analyseert de volledige headerketen van elke getroffen e-mail, met patroonherkenning op honderden bekende migratietool-handtekeningen om exact te identificeren welke headers correctie nodig hebben. Het meerfasige analyseproces verwerkt de randgevallen die eenvoudigere benaderingen doen falen: S/MIME-ondertekende berichten, PGP-versleutelde inhoud, multipart/alternative-structuren, Content-Transfer-Encoding-problemen, niet-ASCII-headers (RFC 2047), oversized bijlagen en beschadigde MIME-grenzen.
Na correctie doorloopt elke e-mail een integriteitsverificatieproces om te bevestigen dat de structuur, inhoud en bijlagen van het bericht identiek zijn bewaard. Originelen worden bewaard in een zichtbare back-upmap gedurende 30 dagen.
Zou u een script kunnen schrijven om deze correctie zelf te proberen? Technisch gezien ja. Maar het verschil tussen "het werkt bij 95% van de e-mails" en "het werkt bij 100% van de e-mails zonder er een te beschadigen" vertegenwoordigt maanden ontwikkeling. En wanneer het over iemands volledige mailbox gaat, betekent een faalpercentage van 5% honderden berichten die stilletjes zijn beschadigd zonder mogelijkheid om te verifieren wat er is misgegaan.
Wilt u weten hoeveel e-mails in uw mailbox verkeerde datums hebben? Start een gratis analyse met Redate.io voor een directe telling van de getroffen e-mails, zonder betaling vereist.