Problemet - alle e-mails viser den samme dato
Efter en IMAP-migrering aabner brugerne deres postkasse og opdager noget foruroligende: hver eneste e-mail viser praecis den samme dato. I stedet for den originale afsendelse- eller modtagelsesdato viser alle beskeder datoen for selve migreringen. Aars korrespondance der tilsyneladende er ankommet paa samme dag.
Det er et mareridt for IT-administratorer. Supportbilletterne vaelter ind, brugerne kan ikke finde noget via datosorteirng, og postkassens kronologiske historik er i praksis oedelagt.
Saadan ser det ud i Outlook
I Microsoft Outlook viser kolonnen "Modtaget" migreringsdatoen for hver e-mail. Uanset om en besked blev sendt i 2018 eller 2023, viser Outlook den samme dato - den dag migreringsvaerktojet behandlede postkassen. Indbakken, sendte elementer, hver mappe er ramt. Brugere der sorterer efter dato faar deres arbejdsgang fuldstaendig oedelagt.
Saadan ser det ud i Apple Mail
Apple Mail paa macOS og iOS opfoerer sig paa samme maade. Datoen ud for hver besked afspejler migreringstidsstemplet snarere end den oprindelige dato. Fordi Apple Mail bruger IMAP-serverens metadata til at bestemme visningsdatoer, giver det samme underliggende problem det samme synlige resultat. Naar man scroller gennem indbakken, ser man bare en mur af identiske datoer.
Saadan ser det ud i Gmail (webgraensefladen)
Gmails webgraenseflade praesenterer en lidt anderledes situation. Gmails webclient bruger normalt e-mailens "Date"-header, saa beskederne kan vises med den korrekte dato i Gmail. Men IMAP INTERNALDATE er stadig forkert, hvilket betyder at enhver IMAP-klient der forbinder til den Gmail-konto (Outlook, Thunderbird, Apple Mail) vil vise migreringsdatoen. Saa den samme postkasse ser korrekt ud i en klient men forkert i en anden. Ret forvirrende.
Hvorfor det sker - den tekniske aarsag
Den grundlaeggende aarsag ligger i maaden IMAP-migreringsvaerktojer haandterer e-mail-headers paa, og hvordan e-mailklienter bestemmer hvilken dato der skal vises. For at forstaa dette kraeves et kort blik paa IMAP-protokollen og headerstrukturen.
Hvordan IMAP-migreringsvaerktojer haandterer headers
Naar en e-mail migreres fra en server til en anden, downloader migreringsvaerktojet den raa besked fra kildeserveren og uploader den til destinationsserveren via IMAP APPEND-kommandoen. Under denne proces kraever IMAP-protokollen at destinationsserveren tilfojer en "Received"-header til beskeden. Denne header indeholder tidsstemplet for hvornaar beskeden blev indsat paa den nye server, altsaa migreringsdatoen.
"Received"-headeren der oedelaegger det hele
E-mailbeskeder indeholder typisk flere "Received"-headers, hver tilfojet af en mailserver der haandterede beskeden under den oprindelige levering. Klienter som Outlook bestemmer "modtagelsesdatoen" ved at laese den nyeste "Received"-header, den oeverst i kaeden. Naar et migreringsvaerktoej tilfojer en ny "Received"-header med migreringstidsstemplet, bliver den den nyeste, og e-mailklienter viser den dato i stedet for den originale.
Det er ikke en fejl i migreringsvaerktojet eller i e-mailklienten. Begge foelger IMAP- og e-mailstandarderne korrekt. Problemet er at disse standarder aldrig var designet til masseflytning, og interaktionen mellem IMAP APPEND og klienternes datovisningslogik producerer dette uoenskede resultat.
INTERNALDATE vs Date-header
IMAP-servere gemmer to forskellige datovaerdier for hver besked. "Date"-headeren er en del af selve e-mailbeskeden og registrerer hvornaar beskeden oprindeligt blev skrevet og sendt. INTERNALDATE er metadata gemt af IMAP-serveren, der repraesenterer hvornaar beskeden blev leveret eller indsat paa den specifikke server.
Nogle migreringsvaerktojer forsoeger at bevare den originale INTERNALDATE ved at saette den under APPEND-kommandoen. Men selv naar INTERNALDATE er korrekt sat, skaber den tilfoejede "Received"-header stadig problemer i klienter der prioriterer "Received"-datoen over INTERNALDATE.
Hvilke migreringsvaerktojer foraarsager dette problem?
Naesten alle IMAP-migreringsvaerktojer kan foraarsage dette problem. Det er iboende i IMAP-protokollen, ikke specifikt for et enkelt vaerktoej. Nogle er dog oftere forbundet med problemet paa grund af deres udbredte brug.
BitTitan MigrationWiz
BitTitan MigrationWiz er et af de mest populaere kommercielle migreringsvaerktojer, brugt af MSP'er og IT-konsulenter. MigrationWiz tilfojer en "Received"-header der indeholder "mx.migrationwiz.com" under migreringsprocessen. Denne header bliver den nyeste i kaeden og foraarsager at migreringsdatoen vises i Outlook og andre IMAP-klienter. Se de detaljerede guider til at rette BitTitan-datoer i Outlook, Microsoft 365, Google Workspace og Exchange Online.
CloudM Migrate
CloudM Migrate (tidligere Cloud Migrator) bruges bredt til Google Workspace-migreringer. Som andre vaerktojer tilfojer CloudM sin egen "Received"-header under IMAP-indsaettelsen. E-mails migreret med CloudM viser migreringsdatoen i klienter der baserer sig paa "Received"-headeren. Se guiderne til at rette CloudM-datoer i Gmail, Outlook, Google Workspace og Microsoft 365.
imapsync
imapsync er et populaert open source-vaerktoej blandt Linux-administratorer og hostingudbydere. Selvom imapsync forsoeger at bevare INTERNALDATE, tilfojer destinationsserveren stadig en "Received"-header under APPEND-operationen. imapsyncs FAQ anerkender denne begraensning men tilbyder ingen indbygget loesning til at fjerne den tilfoejede header efter migrering. Se guiderne til at rette imapsync-datoer i Outlook, Gmail, Microsoft 365 og Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) er Googles eget vaerktoej til migrering fra Exchange eller Outlook PST-filer til Google Workspace. GSMMO kan producere det samme datoproblem, saerligt naar migreringen involverer et mellomliggende IMAP-trin. Se guiderne til at rette GSMMO-datoer i Outlook, Gmail og Apple Mail.
Exchange Admin Center (indbygget IMAP-import)
Microsofts Exchange Administration Center indeholder en indbygget IMAP-importfunktion til migrering til Exchange Online (Microsoft 365). Dette indbyggede migreringsvaerktoej tilfojer "Received"-headers under importen og foraarsager det samme datovisningsproblem. Se guiderne til at rette Exchange IMAP-migreringsdatoer i Outlook og OWA.
Manuel IMAP-kopi
Selv manuel kopiering af e-mails mellem IMAP-servere via en klient som Thunderbird kan producere dette datoproblem. Naar en e-mailklient kopierer en besked via IMAP, behandler destinationsserveren det som en ny indsaettelse og tilfojer sin egen "Received"-header med det aktuelle tidsstempel. Se guiderne til at rette manuelle IMAP-kopidatoer i Outlook, Gmail, Thunderbird og Apple Mail.
Hvorfor de gaengse workarounds ikke virker
Naar brugere og administratorer staar over for dette problem, proever de typisk flere tilgange foer de indser at ingen af dem faktisk loeser problemet.
"Sorter efter afsendelsesdato" - hvorfor det ikke er nok
Det mest udbredte raad er at skifte fra sortering efter "modtagelsesdato" til "afsendelsesdato" i e-mailklienten. Det aendrer ganske vist visningsraekkefoelgen, men det retter ikke de underliggende data. Soegeresultater viser stadig den forkerte dato. Kalenderintegrationer, compliancevaerktojer og automatiserede workflows der afhaenger af modtagelsesdatoen fortsaetter med at fejle. Og brugerne skal huske at aendre denne indstilling paa hver enhed og i hver mappe.
Re-migrering - dyrt og risikabelt
Nogle administratorer overvejer at koere migreringen igen i haab om at undgaa datoproblemet i anden omgang. Denne tilgang er dyr (500 til 5.000 EUR afhaengigt af antallet af postkasser), tidskraevende og risikabel. En anden migrering introducerer det samme "Received"-header-problem, fordobler risikoen for datatab og kraever betydelig nedetid. Re-migrering loeser ikke datoproblemet medmindre migreringsvaerktojet er fundamentalt aendret.
Manuel headerredigering - kraever serveradgang
Teknisk set indebaerer rettelsen at fjerne migrerings-"Received"-headeren fra hver e-mail. Men at goere det manuelt kraever direkte serveradgang, kendskab til e-mail-headerstruktur og specialskrevet scripting. For en postkasse med 10.000 e-mails er manuel redigering upraktisk og farligt fejludsat. S/MIME-signerede e-mails, PGP-krypterede beskeder, multipart-strukturer med indlejrede MIME-graenser, Content-Transfer-Encoding-problemer, ikke-ASCII-headers (RFC 2047), overstore vedhaeftninger - hvert af disse tilfaelde kan faa et basalt script til at korrumpere data irreversibelt. Hvordan bekraefter du at 10.000 rettede e-mails alle er intakte? Det kan du ikke, medmindre du har et verifikationssystem bygget specifikt til det.
Den rigtige loesning - gendan de originale datoer
Den korrekte tilgang er at identificere migreringsartefakter i hver e-mails headerkade og anvende maalrettede korrektioner der gendanner den originale kronologiske raekkefoelge i alle e-mailklienter. Det er ikke bare en simpel headerredigering. Processen indebaerer RFC-compliancevalidering, bevarelse af beskedstrukturen og matchning af migreringssignaturer fra en database af kendte vaerktojsprofiler.
Hvordan Redate.io retter problemet
Redate.io forbinder til postkassen (Google Workspace, Microsoft 365 eller enhver IMAP-server) og analyserer hver e-mail for at identificere beskeder paavirket af migrerings-headers. Analysen er gratis og viser praecis hvor mange e-mails der er ramt, foer der betales noget.
For hver paavirket e-mail koerer Redate.io's proprietaere korrektionsmotor beskeden gennem en flertrins analysepipeline. Motoren anvender moenstergenkendelse paa hundredvis af kendte migreringsvaerktojssignaturer, opbygget gennem behandling af store maengder faktiske e-maildata. Den haandterer encodingproblemer, multipart-strukturer, inline-vedhaeftninger og snesevis af saertilfaelde der ville faa et DIY-script til at korrumpere data (ikke den slags opdagelse du oensker en mandag morgen). Hver rettet e-mail gennemgaar en integritetsverifikation foer den faerdiggoeres. Den originale besked flyttes til en synlig mappe "Redate.io - Originals" (ikke slettet) og bevares i 30 dage.
Resultatet? E-mails viser deres originale korrekte datoer i alle klienter. Sortering fungerer igen. Postkassens kronologiske historik er gendannet.
Ofte stillede spoergsmaal
Kan datoer rettes maaneder efter migreringen?
Ja. Den originale "Date"-header er bevaret inde i e-mailbeskeden uafhaengigt af hvornaar migreringen fandt sted. Redate.io kan rette e-maildatoer uger, maaneder eller endda aar efter migreringen. Rettelsen virker saa laenge de originale e-mail-headers er intakte.
Sletter rettelsen mine e-mails?
Nej. Redate.io sletter aldrig e-mails. De originale beskeder flyttes til en synlig mappe kaldet "Redate.io - Originals" i postkassen, hvor de forbliver tilgaengelige i 30 dage. Hver rettet e-mail verificeres mod originalen foer processen afsluttes. Hvis verifikationen fejler for en besked, forbliver originalen urort.
Virker det med delte postkasser?
Ja. Redate.io fungerer med delte postkasser i Google Workspace og Microsoft 365. For delte postkasser kraeves administratoradgang for at godkende forbindelsen. Processen er identisk med individuelle postkasser: analyse, rettelse, verifikation.
Klar til at gendanne de rigtige datoer? Start en gratis analyse for at se hvor mange e-mails der er paavirket i hver postkasse.