Hvorfor har dine e-mails forkert dato efter migrering

Problemet - alle e-mails viser den samme dato

Efter en IMAP-migrering åbner brugerne deres postkasse og opdager noget foruroligende: hver eneste e-mail viser præcis den samme dato. I stedet for den originale afsendelse- eller modtagelsesdato viser alle beskeder datoen for selve migreringen. Års korrespondance der tilsyneladende er ankommet på samme dag.

Det er et mareridt for IT-administratorer. Supportbilletterne vælter ind, brugerne kan ikke finde noget via datosortering, og postkassens kronologiske historik er i praksis ødelagt.

Sådan 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 migreringsværktojet behandlede postkassen. Indbakken, sendte elementer, hver mappe er ramt. Brugere der sorterer efter dato får deres arbejdsgang fuldstændig ødelagt.

Sådan ser det ud i Apple Mail

Apple Mail på macOS og iOS opfører sig på samme måde. Datøn 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. Når man scroller gennem indbakken, ser man bare en mur af identiske datoer.

Sådan ser det ud i Gmail (webgrænsefladen)

Gmails webgrænseflade præsenterer en lidt anderledes situation. Gmails webclient bruger normalt e-mailens "Date"-header, så 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. Så den samme postkasse ser korrekt ud i en klient men forkert i en anden. Ret forvirrende.

Hvorfor det sker - den tekniske årsag

Den grundlæggende årsag ligger i måden IMAP-migreringsværktojer håndterer e-mail-headers på, og hvordan e-mailklienter bestemmer hvilken dato der skal vises. For at forstå dette kræves et kort blik på IMAP-protokollen og headerstrukturen.

Hvordan IMAP-migreringsværktojer håndterer headers

Når en e-mail migreres fra en server til en anden, downloader migreringsværktojet den rå besked fra kildeserveren og uploader den til destinationsserveren via IMAP APPEND-kommandøn. Under denne proces kræver IMAP-protokollen at destinationsserveren tilfojer en "Received"-header til beskeden. Denne header indeholder tidsstemplet for hvornår beskeden blev indsat på den nye server, altså migreringsdatoen.

"Received"-headeren der ødelægger det hele

E-mailbeskeder indeholder typisk flere "Received"-headers, hver tilfojet af en mailserver der håndterede beskeden under den oprindelige levering. Klienter som Outlook bestemmer "modtagelsesdatoen" ved at læse den nyeste "Received"-header, den øverst i kæden. Når et migreringsværktøj 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 migreringsværktojet eller i e-mailklienten. Begge følger 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 uønskede resultat.

INTERNALDATE vs Date-header

IMAP-servere gemmer to forskellige datoværdier for hver besked. "Date"-headeren er en del af selve e-mailbeskeden og registrerer hvornår beskeden oprindeligt blev skrevet og sendt. INTERNALDATE er metadata gemt af IMAP-serveren, der repræsenterer hvornår beskeden blev leveret eller indsat på den specifikke server.

Nogle migreringsværktojer forsøger at bevare den originale INTERNALDATE ved at sætte den under APPEND-kommandøn. Men selv når INTERNALDATE er korrekt sat, skaber den tilføjede "Received"-header stadig problemer i klienter der prioriterer "Received"-datoen over INTERNALDATE.

Hvilke migreringsværktojer forårsager dette problem?

Næsten alle IMAP-migreringsværktojer kan forårsage dette problem. Det er ibønde i IMAP-protokollen, ikke specifikt for et enkelt værktøj. Nogle er dog oftere forbundet med problemet på grund af deres udbredte brug.

BitTitan MigrationWiz

BitTitan MigrationWiz er et af de mest populære kommercielle migreringsværktojer, 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 kæden og forårsager 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 værktojer tilfojer CloudM sin egen "Received"-header under IMAP-indsættelsen. E-mails migreret med CloudM viser migreringsdatoen i klienter der baserer sig på "Received"-headeren. Se guiderne til at rette CloudM-datoer i Gmail, Outlook, Google Workspace og Microsoft 365.

imapsync

imapsync er et populært open source-værktøj blandt Linux-administratorer og hostingudbydere. Selvom imapsync forsøger at bevare INTERNALDATE, tilfojer destinationsserveren stadig en "Received"-header under APPEND-operationen. imapsyncs FAQ anerkender denne begrænsning men tilbyder ingen indbygget løsning til at fjerne den tilføjede 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 værktøj til migrering fra Exchange eller Outlook PST-filer til Google Workspace. GSMMO kan producere det samme datoproblem, særligt når 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 migreringsværktøj tilfojer "Received"-headers under importen og forårsager 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. Når en e-mailklient kopierer en besked via IMAP, behandler destinationsserveren det som en ny indsættelse 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 gængse workarounds ikke virker

Når brugere og administratorer står over for dette problem, prøver de typisk flere tilgange før de indser at ingen af dem faktisk løser problemet.

"Sorter efter afsendelsesdato" - hvorfor det ikke er nok

Det mest udbredte råd er at skifte fra sortering efter "modtagelsesdato" til "afsendelsesdato" i e-mailklienten. Det ændrer ganske vist visningsrækkefølgen, men det retter ikke de underliggende data. Søgeresultater viser stadig den forkerte dato. Kalenderintegrationer, complianceværktojer og automatiserede workflows der afhænger af modtagelsesdatoen fortsætter med at fejle. Og brugerne skal huske at ændre denne indstilling på hver enhed og i hver mappe.

Re-migrering - dyrt og risikabelt

Nogle administratorer overvejer at køre migreringen igen i håb om at undgå datoproblemet i anden omgang. Denne tilgang er dyr (500 til 5.000 EUR afhængigt af antallet af postkasser), tidskrævende og risikabel. En anden migrering introducerer det samme "Received"-header-problem, fordobler risikøn for datatab og kræver betydelig nedetid. Re-migrering løser ikke datoproblemet medmindre migreringsværktojet er fundamentalt ændret.

Manuel headerredigering - kræver serveradgang

Teknisk set indebærer rettelsen at fjerne migrerings-"Received"-headeren fra hver e-mail. Men at gøre det manuelt kræver 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-grænser, Content-Transfer-Encoding-problemer, ikke-ASCII-headers (RFC 2047), overstore vedhæftninger - hvert af disse tilfælde kan få et basalt script til at korrumpere data irreversibelt. Hvordan bekræfter 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 løsning - gendan de originale datoer

Den korrekte tilgang er at identificere migreringsartefakter i hver e-mails headerkade og anvende målrettede korrektioner der gendanner den originale kronologiske rækkefølge i alle e-mailklienter. Det er ikke bare en simpel headerredigering. Processen indebærer RFC-compliancevalidering, bevarelse af beskedstrukturen og matchning af migreringssignaturer fra en database af kendte værktojsprofiler.

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 påvirket af migrerings-headers. Analysen er gratis og viser præcis hvor mange e-mails der er ramt, før der betales noget.

For hver påvirket e-mail kører Redate.io's proprietære korrektionsmotor beskeden gennem en flertrins analysepipeline. Motoren anvender mønstergenkendelse på hundredvis af kendte migreringsværktojssignaturer, opbygget gennem behandling af store mængder faktiske e-maildata. Den håndterer encodingproblemer, multipart-strukturer, inline-vedhæftninger og snesevis af særtilfælde der ville få et DIY-script til at korrumpere data (ikke den slags opdagelse du ønsker en mandag morgen). Hver rettet e-mail gennemgår en integritetsverifikation før den færdiggøres. 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 spørgsmål

Kan datoer rettes måneder efter migreringen?

Ja. Den originale "Date"-header er bevaret inde i e-mailbeskeden uafhængigt af hvornår migreringen fandt sted. Redate.io kan rette e-maildatoer uger, måneder eller endda år efter migreringen. Rettelsen virker så længe 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 tilgængelige i 30 dage. Hver rettet e-mail verificeres mod originalen før 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 kræves 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 påvirket i hver postkasse.