Feil e-postdatoer etter Zoho-migrering til Microsoft 365

Hva som skjedde med postboksen din

Du har nettopp fullført migreringen av domenet ditt fra Zoho Mail til Microsoft 365. Exchange Online er på plass, postboksene er klargjort, MX-postene er oppdatert. Og så, mandag morgen, åpner en bruker Outlook og ser at alle e-poster fra 2021 viser dagens dato. En annen merker at meldinger fra i fjor havner øverst i innboksen, som om de akkurat ble mottatt. Supportsaker begynner å strømme inn.

Dette er ikke en Outlook-feil. Det er heller ikke noe spesifikt for Zoho. Det er den forventede, men dårlig dokumenterte, oppførselen til enhver IMAP-migrering til Exchange Online. Å forstå nøyaktig hvorfor det skjer, er første steg mot en ordentlig løsning.

Den tekniske årsaken: INTERNALDATE og Received-hoder

En e-post lagret på en IMAP-server består av to atskilte ting: det rå meldingsinnholdet (RFC 2822-hoder, brødtekst, vedlegg) og lagringsmetadata som serveren håndterer, inkludert INTERNALDATE. Det er denne metadataen e-postklienter bruker for å vise og sortere meldinger.

Date:-hodet i selve meldingen (RFC 2822) representerer datoen da meldingen ble skrevet eller sendt av avsenderen. INTERNALDATE er datoen da IMAP-serveren mottok eller lagret meldingen. Normalt er disse to verdiene nær hverandre på en velfungerende server. Etter en migrering er det en helt annen historie.

Slik ødelegger IMAP-migrering datoene

Når et migreringsverktøy (Zoho Migration Wizard, imapsync, BitTitan eller noe annet) overfører en melding fra Zoho Mail til Exchange Online, skjer det via IMAP-protokollen. Verktøyet kobler seg til Zoho, henter meldingen og setter den inn i Exchange Online via en IMAP APPEND-kommando. Og det er her det går galt.

Exchange Online genererer et nytt Received:-hode for hver melding som mottas, og legger det øverst i meldingen. Dette hodet bærer nøyaktig dato og klokkeslett for innsettingen, altså migrasjonsdatoen. Noen verktøy forsøker å bevare den originale INTERNALDATE ved å sende den som parameter til APPEND-kommandoen. Andre gjør det ikke, eller gjør det feil, og da tildeler Exchange Online automatisk mottakstidspunktet som INTERNALDATE.

Resultatet: enten e-posten ble sendt i 2019 eller 2022, peker nå INTERNALDATE mot migrasjonsuken. Outlook leser denne verdien med prioritet. Sorteringen kollapser.

Zoho Migration Wizards spesifikke oppførsel

Zoho tilbyr sitt eget verktøy for å flytte bort fra plattformen: Zoho Migration Wizard. Det er praktisk for enkle migreringer, men har en dokumentert oppførsel på adminforum: det sender ikke alltid INTERNALDATE korrekt når meldinger settes inn på målserveren.

For å være presis: problemet rammer særlig migreringer til servere som systematisk legger til et Received:-hode på alle innkommende meldinger, noe som er nøyaktig hva Exchange Online gjør. Selv om Zoho Migration Wizard sender den originale datoen via APPEND-parameteren, havner Received:-hodet generert av Exchange Online øverst i hodekjeden, og Outlook bruker det til å bestemme "når e-posten ankom".

Adminer som bruker generiske IMAP-verktøy som imapsync for å forlate Zoho, opplever nøyaktig det samme problemet, noen ganger verre, fordi standardkonfigurasjonen til imapsync ikke er optimalisert for Exchange Online. (Har du noen gang gått gjennom en imapsync-logg linje for linje klokken 02.00 på jakt etter en synkroniseringsfeil, vet du at det er et kraftig verktøy, men ikke akkurat tilgivende for kanttilfeller.)

Hvorfor Outlook viser feil dato

Outlook bruker ikke bare Date:-hodet for å vise datoen på en e-post. I de fleste visninger er det INTERNALDATE fra IMAP/Exchange-serveren som brukes, særlig for sortering av innboksen. Det originale Date:-hodet er der, intakt, men ignoreres til fordel for INTERNALDATE.

Det er derfor "Sorter etter sendedato" i Outlook egentlig ikke løser problemet. Den viser en annen dato, ja, men sorteringsoppførselen forblir ustabil på tvers av Outlook-versjoner og visningsmoduser (grupperte samtaler eller ikke). Sortering etter sendedato er ikke en løsning. Det er et plaster som faller av ved første klientoppdatering.

Det faktiske omfanget av problemet

I en middels stor Zoho-til-Microsoft 365-migrering snakker vi lett om 50 000 til 500 000 berørte meldinger, avhengig av postboksenes alder og organisasjonens størrelse. Hver e-post overført i migrasjonsvindutiden bærer den samme korrupte datoen, noe som gjør problemet umiddelbart synlig for brukerne ved første åpning av Outlook.

Sendt-mapper er ofte verst. En selger som leter etter et tilbud sendt i mars 2022, må grave gjennom hundrevis av e-poster som alle viser migrasjonsdatoen. Den operative konsekvensen er reell, ikke bare kosmetisk.

Og i motsetning til hva man kanskje tror, forsvinner ikke problemet over tid. INTERNALDATE er satt ved innsetting. Den retter seg ikke selv. Uten aktiv inngripen beholder e-postene sin korrupte dato på ubestemt tid.

Hvorfor det er mer risikabelt å fikse dette selv enn det ser ut

Fristelsen er forståelig: siden det originale Date:-hodet alltid er i meldingen, er det bare å... rette metadataen. På papiret logisk. I praksis, på en produksjonspostboks med 80 000 e-poster, kan det gå katastrofalt galt.

Her er noen kanttilfeller et hjemmelaget skript sannsynligvis ikke håndterer bra:

• S/MIME-signerte e-poster, der signaturen dekker alle hodene. Å endre noe som helst i meldingsstrukturen ugyldiggjør den kryptografiske signaturen.
• PGP-krypterte meldinger, der innholdet er ugjennomsiktig og enhver manipulasjon av MIME-konvolutter kan ødelegge meldingen.
• Ikke-ASCII-hoder kodet i RFC 2047 (avsendernavn med spesialtegn), som knekker hvis skriptet ikke håndterer kodingen korrekt.
• Base64-kodede vedlegg med feil linjeavslutninger, ikke-standard MIME-grenser eller nestede multipart-strukturer.
• E-poster uten gyldig Date:-hode (det finnes slike, særlig i gamle Zoho-eksporter), der skriptet må bestemme hva det skal gjøre.

Et skript som fungerer på 50 teste-poster, fungerer ikke på en produksjonspostboks fra Zoho eksportert med årevis av historikk. Og hvordan verifiserer du, melding for melding, at hver korreksjon er intakt og at vedlegg ikke er avkortet? Verifikasjon er minst like komplekst som selve rettingen.

Det er også spørsmålet om kvoter. Exchange Online API-et via Microsoft Graph har strenge hastighetsbegrensninger (de berømte 429 Too Many Requests-feilene). En ubegrenset batch på 100 000 meldinger kan utløse midlertidige blokkeringer eller stille feil som er vanskelig å diagnostisere i ettertid. Uten en mekanisme for gjenopptakelse etter feil begynner du på nytt fra begynnelsen.

Slik retter Redate.io datoene etter Zoho-migrering

Redate.io kobler seg til Microsoft 365-tenanten din via standard Azure AD-tillatelser, uten global admin-tilgang. Det første skannet er gratis: Redate.io identifiserer berørte postbokser og estimerer volumet av e-poster med feil datoer, ved å sammenligne INTERNALDATE med verdiene i meldingenes hodekjede.

Rettingen bruker en proprietær motor som analyserer den komplette hodekjeden i hver melding, identifiserer spesifikke signaturer fra Zoho-migreringsverktøy (enten Zoho Migration Wizard eller imapsync konfigurert for Zoho-avgang), og rekonstruerer datometadata via en flerstegs valideringspipeline. Hver rettet e-post verifiseres individuelt: innholdsintegritet, bevaring av vedlegg, RFC-samsvar. Originalene beholdes i en sikkerhetskopieringsmappe som er tilgjengelig i 30 dager.

Ingen re-migrering. Ingen nedetid. Brukerne fortsetter å bruke Outlook mens rettingen kjører i bakgrunnen.

Prissettingen er et engangsbeløp basert på volum, uten abonnement. Detaljer finnes direkte på nettstedet.

Beslektede scenarier du bør kjenne til

Hvis du håndterer flere migreringer parallelt, eller er MSP og administrerer kunder som forlater Zoho, er det verdt å vite at samme problem oppstår ved migreringer fra andre plattformer til Exchange Online. Mekanikken er identisk: Received:-hodet generert av Exchange overskriver INTERNALDATE uavhengig av kilden.

For migreringer fra Google Workspace, fra Exchange on-premises, eller via verktøy som BitTitan MigrationWiz eller CloudM, finner du dedikerte artikler på Redate.io-bloggen som beskriver den spesifikke oppførselen til hvert verktøy. Artikkelen om feil e-postdatoer etter migrering til Exchange Online gir en oversikt over alle scenariene som ender opp på denne tenanten.

Hvis migreringen din inkluderer delte postbokser eller Exchange-ressurser (rom, utstyr), er problemet det samme, og de samme retteverktøyene gjelder. Guiden Rett Exchange IMAP-migreringsdatoer i Outlook på Redate.io beskriver stegene for å koble til tenanten din.

For team som bruker imapsync spesifikt for å forlate Zoho, dokumenterer artikkelen imapsync: datoer ikke bevart imapsync-konfigurasjonsalternativer og hvorfor de ikke er nok til å unngå problemet på Exchange Online.

Viser Outlook fremdeles Zoho-migrasjonsdatoene dine? Skann postboksene gratis på Redate.io for å måle det nøyaktige omfanget av problemet før du bestemmer deg for hvordan du vil gå frem.