Forkerte datoer efter Zoho-migrering til Microsoft 365

Det der skete med din postkasse

Du har netop afsluttet migreringen af dit domæne fra Zoho Mail til Microsoft 365. Exchange Online-infrastrukturen er på plads, postkasserne er klargjort, MX-posterne er opdateret. Og så mandag morgen åbner en bruger Outlook og opdager, at alle e-mails fra 2021 viser dagens dato. En anden konstaterer, at beskeder fra sidste år er sorteret øverst i indbakken, som om de netop er ankommet. Supporttikterne begynder at strømme ind.

Det er ikke en Outlook-fejl. Det er heller ikke et problem specielt for Zoho. Det er den forventede, men dårligt dokumenterede adfærd ved enhver IMAP-migrering til Exchange Online. At forstå præcis, hvorfor det sker, er det første skridt mod en ordentlig løsning.

Den tekniske årsag: INTERNALDATE og Received-headere

En e-mail gemt på en IMAP-server består af to adskilte dele: det rå beskedindhold (RFC 2822-headere, brødtekst, vedhæftede filer) og de lagringsmetadata, som IMAP-serveren styrer, herunder INTERNALDATE. Det er denne metadata, som e-mailklienter bruger til at vise og sortere beskeder.

Date:-headeren i den rå besked (RFC 2822) angiver datoen for, hvornår beskeden blev skrevet eller sendt af afsenderen. INTERNALDATE er derimod datoen for, hvornår IMAP-serveren modtog eller gemte beskeden. Normalt ligger disse to værdier tæt på hinanden. Efter en migrering er det en helt anden sag.

Sådan ødelægger IMAP-migrering datoerne

Når et migreringsværktøj (Zoho Migration Wizard, imapsync, BitTitan eller et hvilket som helst andet) overfører en besked fra Zoho Mail til Exchange Online, sker det via IMAP-protokollen. Værktøjet forbinder sig til Zoho, henter beskeden og indsætter den i Exchange Online via en IMAP APPEND-kommando. Og det er her, det går galt.

Exchange Online genererer en ny Received:-header for hver besked, som sættes øverst i headerkæden. Denne header bærer det præcise tidspunkt for indsætningen, altså migrationsdatoen. Nogle migreringsværktøjer forsøger at bevare den originale INTERNALDATE ved at sende den som parameter til APPEND-kommandoen. Andre gør det ikke, eller gør det forkert, og Exchange Online tildeler da automatisk modtagelsesdatoen som INTERNALDATE.

Resultatet: uanset om en e-mail blev sendt i 2019 eller 2022, peger dens INTERNALDATE nu på migrationsugen. Outlook læser denne værdi med prioritet. Sorteringen bryder sammen.

Zoho Migration Wizards specifikke adfærd

Zoho tilbyder sit eget migreringsværktøj til at forlade platformen: Zoho Migration Wizard. Det er praktisk til simple migreringer, men det har en dokumenteret adfærd på adminforums: det videresender ikke altid den originale INTERNALDATE korrekt ved indsætning på destinationsserveren.

For at være præcis rammer problemet primært migreringer til servere, der systematisk tilføjer en Received:-header til hver indgående besked, hvilket er præcis, hvad Exchange Online gør. Selv hvis Zoho Migration Wizard sender den originale dato via APPEND-parameteren, ender Received:-headeren genereret af Exchange Online som den første i headerkæden, og Outlook bruger den til at bestemme "hvornår e-mailen ankom".

Admins der bruger generiske IMAP-værktøjer som imapsync til at forlade Zoho oplever nøjagtig det samme problem, nogle gange endnu værre, fordi imapsyncs standardkonfiguration ikke er optimeret til Exchange Online. (Og hvis du nogensinde har skimmet en imapsync-log linje for linje kl. 2 om natten for at finde en synkroniseringsfejl, ved du, at det er et kraftfuldt værktøj, der bestemt ikke er nådigt over for edge cases.)

Hvorfor Outlook viser den forkerte dato

Outlook bruger ikke udelukkende Date:-headeren til at vise en e-mails dato. I langt de fleste visninger er det INTERNALDATE fra IMAP/Exchange-serveren, der bruges, særligt til sortering af indbakken. Den originale Date:-header er ganske vist til stede i beskeden, intakt, men den ignoreres til fordel for INTERNALDATE.

Det er derfor, at funktionen "Sortér efter afsendelsesdato" i Outlook ikke rigtig løser problemet. Den viser en anden dato, ja, men sorteringsadfærden forbliver ustabil afhængigt af Outlook-version og visningsindstillinger (grupperede samtaler eller ej). Sortering efter afsendelsesdato er ikke en løsning. Det er et plaster, der falder af ved første klientopdatering.

Problemets reelle omfang

Ved en mellemstor Zoho-til-Microsoft 365-migrering taler vi nemt om 50.000 til 500.000 berørte beskeder, afhængigt af postkassernes alder og organisationens størrelse. Hver e-mail overført i migreringsvinduet bærer den samme korrupte dato, hvilket gør problemet umiddelbart synligt for brugerne ved den første åbning af Outlook.

Mappen Sendte elementer er ofte den mest problematiske. En sælger, der leder efter et tilbud sendt i marts 2022, ender med at grave i hundredvis af e-mails, der alle viser migrationsdatoen. Den driftsmæssige konsekvens er reel, ikke blot kosmetisk.

Og i modsætning til hvad man måske tror, forsvinder problemet ikke med tiden. INTERNALDATE fastsættes på indsætningstidspunktet. Det retter sig ikke selv. Uden aktiv indgriben beholder e-mails deres korrupte dato på ubestemt tid.

Hvorfor det er mere risikabelt at rette selv, end det ser ud

Fristelsen er forståelig: siden den originale Date:-header stadig er i beskeden, handler det vel bare om at... rette metadataene. På papiret er det logisk. I praksis, på en produktionspostkasse med 80.000 e-mails, er det en operation, der kan gå katastrofalt galt.

Her er nogle edge cases, som et hjemmelavet script sandsynligvis ikke håndterer godt:

• S/MIME-signerede e-mails, hvor signaturen dækker alle headere. At ændre noget som helst i beskedens struktur ugyldiggør den kryptografiske signatur.
• PGP-krypterede beskeder, hvor indholdet er uigennemsigtigt, og enhver manipulation af MIME-enveloppen kan ødelægge beskeden.
• Ikke-ASCII-headere encodet efter RFC 2047 (afsendernavne med specialtegn), der bryder, hvis scriptet ikke håndterer encoding korrekt.
• Base64-encodede vedhæftede filer med dårligt terminerede linjer, ikke-standard MIME-grænser eller indlejrede multipart-strukturer.
• E-mails uden en gyldig Date:-header (det forekommer, særligt i gamle Zoho-eksporter), hvor scriptet skal beslutte, hvad det skal gøre.

Et script, der fungerer på 50 test-e-mails, fungerer ikke på en produktionspostkasse fra Zoho med flere års historik. Og hvordan verificerer du, besked for besked, at hver rettelse er intakt, og at vedhæftede filer ikke er blevet afkortet? Verifikationen er mindst lige så kompleks som selve rettelsen.

Hertil kommer kvotespørgsmålet. Exchange Online API'en via Microsoft Graph har strenge hastighedsbegrænsninger (de berømte 429 Too Many Requests-fejl). Et ukontrolleret batch på 100.000 beskeder kan udløse midlertidige blokeringer eller stille fejl, der er svære at diagnosticere bagefter. Uden en mekanisme til at genoptage ved fejl starter du forfra.

Sådan retter Redate.io datoer efter Zoho-migrering

Redate.io forbinder sig til din Microsoft 365-tenant via standard Azure AD-tilladelser, uden global adminadgang. Det indledende scan er gratis: Redate.io identificerer de berørte postkasser og estimerer volumenet af e-mails med forkerte datoer ved at sammenligne INTERNALDATE med de værdier, der er i beskedens headerkæde.

Rettelsen bruger en proprietær korrektionsmotor, der analyserer den komplette headerkæde for hver besked, identificerer specifikke signaturer fra Zoho-migreringsværktøjer (hvad enten det er Zoho Migration Wizard eller imapsync konfigureret til en Zoho-exit), og rekonstruerer datometadata via en multi-trins valideringspipeline. Hver rettet e-mail verificeres individuelt: indholdsintegritet, bevarelse af vedhæftede filer, RFC-overensstemmelse. Originalerne opbevares i en tilgængelig sikkerhedskopimapp i 30 dage.

Ingen re-migrering. Intet nedetid. Brugerne fortsætter med at bruge Outlook, mens rettelsen kører i baggrunden.

Prisen er en enkelt betaling baseret på volumen, uden abonnement. Detaljerne findes direkte på websitet.

Beslægtede scenarier at kende til

Hvis du administrerer flere migreringer parallelt, eller hvis du er MSP og styrer kunder, der forlader Zoho, skal du vide, at det samme problem opstår ved migreringer fra andre platforme til Exchange Online. Mekanikken er identisk: Received:-headeren genereret af Exchange overskriver INTERNALDATE uanset kilden.

For migreringer fra Google Workspace, fra Exchange on-premises, eller via værktøjer som BitTitan MigrationWiz eller CloudM, beskriver de dedikerede artikler på Redate.io-bloggen den specifikke adfærd for hvert værktøj. Artiklen Forkerte e-maildatoer efter migration til Exchange Online giver et overblik over alle scenarier, der ender på denne tenant.

Hvis din migrering involverer delte postkasser eller Exchange-ressourcer (mødelokaler, udstyr), er problemet det samme, og de samme korrekturværktøjer gælder. Guiderne til at rette IMAP til Exchange på Redate.io-websitet beskriver forbindelsestrinene til din tenant.

For teams, der bruger imapsync specifikt til at forlade Zoho, dokumenterer artiklen imapsync: datoer ikke bevaret imapsyncs konfigurationsmuligheder og hvorfor de ikke er nok til at undgå problemet på Exchange Online.

Vises dine Zoho-migrationsdatoer stadig i Outlook? Scan dine postkasser gratis på Redate.io for at måle problemets præcise omfang, før du beslutter dig for, hvordan du vil handle.