Het probleem - alle e-mails tonen dezelfde datum
Na een IMAP-migratie openen gebruikers hun mailbox en stuiten op een verontrustend beeld: elke e-mail toont exact dezelfde datum. In plaats van de oorspronkelijke verzenddatum staat op alle berichten de datum waarop de migratie is uitgevoerd. Jaren aan correspondentie lijken op een en dezelfde dag te zijn binnengekomen.
Voor IT-beheerders is dit een nachtmerrie. De tickets stromen binnen, gebruikers kunnen niets meer terugvinden op datum, en de chronologische volgorde van de mailbox is in de praktijk vernietigd.
Hoe het eruitziet in Outlook
In Microsoft Outlook toont de kolom "Ontvangen" de migratiedatum voor elke e-mail. Of een bericht nu in 2018 of in 2023 is verstuurd, Outlook toont dezelfde datum - die van de dag waarop de migratietool de mailbox heeft verwerkt. Het postvak IN, de verzonden items, elke map is getroffen. Gebruikers die op datumsortering vertrouwen, zien hun workflow volledig kapot gaan.
Hoe het eruitziet in Apple Mail
Apple Mail op macOS en iOS gedraagt zich vergelijkbaar. De datum naast elk bericht weerspiegelt het migratietijdstempel in plaats van de oorspronkelijke datum. Omdat Apple Mail de IMAP-metadata van de server gebruikt om weergavedatums te bepalen, levert hetzelfde onderliggende probleem hetzelfde zichtbare resultaat op. Bij het bladeren door het postvak ziet u alleen maar een muur van identieke datums.
Hoe het eruitziet in Gmail (webinterface)
De webinterface van Gmail presenteert een iets andere situatie. De Gmail-webclient gebruikt doorgaans de "Date"-header van de e-mail zelf, waardoor berichten in Gmail met de juiste datum kunnen verschijnen. Maar de IMAP INTERNALDATE blijft verkeerd, wat betekent dat elke IMAP-client die verbinding maakt met dit Gmail-account (Outlook, Thunderbird, Apple Mail) de migratiedatum toont. Dezelfde mailbox lijkt dus correct in de ene client maar fout in de andere. Behoorlijk verwarrend, eigenlijk.
Waarom dit gebeurt - de technische oorzaak
De kernoorzaak ligt in de manier waarop IMAP-migratietools omgaan met e-mailheaders en hoe e-mailclients bepalen welke datum ze tonen. Om dit te begrijpen is een korte blik op het IMAP-protocol en de headerstructuur nodig.
Hoe IMAP-migratietools headers verwerken
Wanneer een e-mail van de ene server naar de andere wordt gemigreerd, downloadt de migratietool het ruwe bericht van de bronserver en uploadt het naar de doelserver via het IMAP APPEND-commando. Tijdens dit proces verplicht het IMAP-protocol de doelserver om een "Received"-header aan het bericht toe te voegen. Deze header bevat het tijdstempel van het moment waarop het bericht in de nieuwe server is geplaatst - dus de migratiedatum.
De "Received"-header die alles kapotmaakt
E-mailberichten bevatten doorgaans meerdere "Received"-headers, elk toegevoegd door een mailserver die het bericht heeft verwerkt tijdens de oorspronkelijke bezorging. Clients zoals Outlook bepalen de "ontvangstdatum" door de meest recente "Received"-header te lezen - die bovenaan de keten staat. Wanneer een migratietool een nieuwe "Received"-header toevoegt met het migratietijdstempel, wordt deze de meest recente, en e-mailclients tonen die datum in plaats van de oorspronkelijke.
Dit is geen bug in de migratietool of de e-mailclient. Beide volgen de IMAP- en e-mailstandaarden correct. Het probleem is dat deze standaarden nooit zijn ontworpen voor massale migratie, en de wisselwerking tussen IMAP APPEND en de datumweergavelogica levert dit ongewenste resultaat op.
INTERNALDATE vs Date-header
IMAP-servers slaan twee verschillende datumwaarden op voor elk bericht. De "Date"-header maakt deel uit van het e-mailbericht zelf en registreert wanneer het bericht oorspronkelijk is opgesteld en verzonden. De INTERNALDATE is metadata die door de IMAP-server wordt opgeslagen en aangeeft wanneer het bericht is bezorgd of geplaatst op die specifieke server.
Sommige migratietools proberen de oorspronkelijke INTERNALDATE te behouden door deze in te stellen tijdens het APPEND-commando. Maar zelfs wanneer de INTERNALDATE correct is ingesteld, veroorzaakt de toegevoegde "Received"-header nog steeds problemen in clients die de "Received"-datum prioriteit geven boven de INTERNALDATE.
Welke migratietools veroorzaken dit probleem?
Vrijwel alle IMAP-migratietools kunnen dit probleem veroorzaken. Het probleem zit in het IMAP-protocol zelf, niet in een specifieke tool. Sommige tools worden er vaker mee geassocieerd vanwege hun wijdverspreide gebruik.
BitTitan MigrationWiz
BitTitan MigrationWiz is een van de populairste commerciele migratietools, veel gebruikt door MSP's en IT-consultants. MigrationWiz voegt een "Received"-header toe die "mx.migrationwiz.com" bevat tijdens het migratieproces. Deze header wordt de meest recente in de keten, waardoor de migratiedatum in Outlook en andere IMAP-clients verschijnt. Zie de gedetailleerde handleidingen voor het herstellen van BitTitan-datums in Outlook, Microsoft 365, Google Workspace en Exchange Online.
CloudM Migrate
CloudM Migrate (voorheen Cloud Migrator) wordt veel gebruikt voor Google Workspace-migraties. Net als andere tools voegt CloudM een eigen "Received"-header toe bij IMAP-insertie. E-mails die met CloudM zijn gemigreerd, tonen de migratiedatum in clients die op de "Received"-header vertrouwen. Zie de handleidingen voor het herstellen van CloudM-datums in Gmail, Outlook, Google Workspace en Microsoft 365.
imapsync
imapsync is een populaire opensourcetool onder Linux-beheerders en hostingproviders. Hoewel imapsync probeert de INTERNALDATE te behouden, voegt de doelserver alsnog een "Received"-header toe tijdens de APPEND-operatie. De FAQ van imapsync erkent deze beperking, maar biedt geen ingebouwde oplossing om de toegevoegde header na migratie te verwijderen. Zie de handleidingen voor het herstellen van imapsync-datums in Outlook, Gmail, Microsoft 365 en Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) is de eigen migratietool van Google voor migratie vanuit Exchange of Outlook PST-bestanden naar Google Workspace. GSMMO kan hetzelfde datumprobleem veroorzaken, met name wanneer de migratie een tussenliggende IMAP-stap omvat. Zie de handleidingen voor het herstellen van GSMMO-datums in Outlook, Gmail en Apple Mail.
Exchange Admin Center (native IMAP-import)
Het Exchange-beheercentrum van Microsoft bevat een native IMAP-importfunctie voor migratie naar Exchange Online (Microsoft 365). Deze ingebouwde migratietool voegt "Received"-headers toe tijdens de import, met hetzelfde datumweergaveprobleem als gevolg. Zie de handleidingen voor het herstellen van Exchange IMAP-migratiedatums in Outlook en OWA.
Handmatige IMAP-kopie
Zelfs het handmatig kopieren van e-mails tussen IMAP-servers via een client zoals Thunderbird kan dit datumprobleem veroorzaken. Wanneer een e-mailclient een bericht via IMAP kopieert, behandelt de doelserver het als een nieuwe insertie en voegt een eigen "Received"-header toe met het huidige tijdstempel. Zie de handleidingen voor het herstellen van handmatige IMAP-kopiedatums in Outlook, Gmail, Thunderbird en Apple Mail.
Waarom veelgebruikte workarounds niet werken
Wanneer dit probleem zich voordoet, proberen gebruikers en beheerders doorgaans meerdere benaderingen voordat ze beseffen dat geen ervan het probleem werkelijk oplost.
"Sorteer op verzenddatum" - waarom dat niet volstaat
De meest gehoorde suggestie is om in de e-mailclient over te schakelen van sorteren op "ontvangstdatum" naar "verzenddatum". Dat verandert inderdaad de weergavevolgorde, maar het herstelt de onderliggende data niet. Zoekresultaten tonen nog steeds de verkeerde datum. Agenda-integraties, compliancetools en geautomatiseerde workflows die afhangen van de ontvangstdatum blijven falen. En gebruikers moeten eraan denken om deze instelling op elk apparaat en in elke map te wijzigen.
Hermigratie - duur en risicovol
Sommige beheerders overwegen de migratie opnieuw uit te voeren, in de hoop het datumprobleem de tweede keer te vermijden. Deze aanpak is kostbaar (500 tot 5.000 EUR afhankelijk van het aantal mailboxen), tijdrovend en risicovol. Een tweede migratie introduceert hetzelfde "Received"-headerprobleem, verdubbelt het risico op gegevensverlies en vereist aanzienlijke downtime. Hermigratie lost het datumprobleem niet op tenzij de migratietool fundamenteel wordt aangepast.
Handmatige headerbewerking - vereist servertoegang
Technisch gezien houdt de correctie in dat de "Received"-migratieheader uit elke e-mail wordt verwijderd. Maar dit handmatig doen vereist directe servertoegang, kennis van e-mailheaderstructuren en op maat gemaakte scripts. Voor een mailbox van 10.000 e-mails is handmatige bewerking onhaalbaar en gevaarlijk foutgevoelig. S/MIME-ondertekende e-mails, PGP-versleutelde berichten, multipart-structuren met geneste MIME-grenzen, Content-Transfer-Encoding-problemen, niet-ASCII-headers (RFC 2047), oversized bijlagen - elk van deze gevallen kan een eenvoudig script ertoe brengen data onherstelbaar te beschadigen. Hoe bevestigt u dat 10.000 gecorrigeerde e-mails allemaal intact zijn? Dat kan niet, tenzij u een verificatiesysteem hebt dat specifiek daarvoor is ontworpen.
De echte oplossing - oorspronkelijke datums herstellen
De juiste aanpak is het identificeren van migratie-artefacten in de headerketen van elke e-mail en het toepassen van gerichte correcties die de oorspronkelijke chronologische volgorde in alle e-mailclients herstellen. Dit is geen simpele headerbewerking. Het proces omvat RFC-conformiteitsvalidatie, behoud van de berichtstructuur en matching van migratiesignaturen uit een database van bekende toolprofielen.
Hoe Redate.io dit probleem oplost
Redate.io maakt verbinding met de mailbox (Google Workspace, Microsoft 365 of elke IMAP-server) en analyseert elke e-mail om berichten te identificeren die door migratieheaders zijn getroffen. De analyse is gratis en toont precies hoeveel e-mails het betreft, nog voor er betaald hoeft te worden.
Voor elke getroffen e-mail stuurt de eigen correctie-engine van Redate.io het bericht door een meerfasig analyseproces. De engine past patroonherkenning toe op basis van honderden bekende migratietool-handtekeningen, opgebouwd uit de verwerking van grote hoeveelheden echte e-maildata. Het systeem verwerkt coderingsproblemen, multipart-structuren, inline-bijlagen en tientallen randgevallen waarbij een DIY-script de data zou beschadigen (niet het soort ontdekking dat u op maandagochtend wilt doen). Elke gecorrigeerde e-mail ondergaat een integriteitscontrole voordat deze wordt afgerond. Het oorspronkelijke bericht wordt verplaatst naar een zichtbare map "Redate.io - Originals" (niet verwijderd) en 30 dagen bewaard.
Het resultaat? E-mails tonen hun correcte oorspronkelijke datums in alle clients. Sortering werkt weer. De chronologische volgorde van de mailbox is hersteld.
Veelgestelde vragen
Kunnen datums maanden na de migratie nog worden hersteld?
Ja. De oorspronkelijke "Date"-header blijft bewaard in het e-mailbericht, ongeacht wanneer de migratie heeft plaatsgevonden. Redate.io kan e-maildatums weken, maanden of zelfs jaren na de migratie herstellen. De correctie werkt zolang de oorspronkelijke headers van de e-mail intact zijn.
Worden er e-mails verwijderd bij het herstellen?
Nee. Redate.io verwijdert nooit e-mails. Oorspronkelijke berichten worden verplaatst naar een zichtbare map genaamd "Redate.io - Originals" in de mailbox, waar ze 30 dagen toegankelijk blijven. Elke gecorrigeerde e-mail wordt geverifieerd ten opzichte van het origineel voordat het proces wordt afgerond. Als de verificatie voor een bericht mislukt, blijft het origineel onaangetast.
Werkt dit met gedeelde mailboxen?
Ja. Redate.io werkt met gedeelde mailboxen in Google Workspace en Microsoft 365. Voor gedeelde mailboxen is beheerderstoegang vereist om de verbinding te autoriseren. Het proces is identiek aan dat van individuele mailboxen: analyse, correctie, verificatie.
Klaar om de juiste datums te herstellen? Start een gratis analyse om te ontdekken hoeveel e-mails in elke mailbox zijn getroffen.