Outlook: mottaksdato IMAP vs sendedato etter migrering

Symptomet alle kjenner igjen

Du har nettopp fullført en IMAP-migrering til Microsoft 365 eller Google Workspace. Mandag morgen strømmer supporthenvendelsene inn: "Alle e-postene mine har samme dato", "Historikken min er ødelagt", "Jeg finner ingenting i innboksen lenger". Du åpner Outlook, og der er det: tusenvis av e-poster som viser datoen for helgen som var. Ikke datoen de ble sendt. Datoen migreringen fant sted.

Dette er ikke en Outlook-feil. Det er en direkte konsekvens av hvordan IMAP-protokollen og migrasjonsverktøy fungerer. Men for å forstå hvorfor, må vi åpne panseret.

Tre datoer i én e-post

En e-post er mer kompleks enn den ser ut. Hode, meldingskropp, vedlegg... og flere separate tidsstempler som eksisterer side om side. (Har du noen gang prøvd å lese rå e-posthoder? Det er ikke akkurat strandlesning.)

Date:-hodet (RFC 2822)

Dette er datoen avsenderen la inn i meldingen da den ble sendt. Definert av RFC 2822, ser den slik ut:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Dette hodet er støpt inn i selve meldingen. Det endres aldri, med mindre noen redigerer råinnholdet direkte. Dette er "sendedatoen" i streng forstand.

Received:-hodet (lagt til ved hvert nettverkshopp)

Hver server som håndterer en e-post underveis, legger til et Received:-hode øverst i meldingen med sin egen dato. En e-post som passerer tre servere, samler opp tre Received:-hoder. Det nyeste ligger alltid øverst. Det ser omtrent slik ut:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Resultatet: når et migrasjonsverktøy som BitTitan MigrationWiz, CloudM, imapsync eller GSMMO flytter en e-post fra en kilde- til en målserver, oppfører det seg selv som et "nettverkshopp". Det injiserer et nytt Received:-hode øverst i stabelen, med dato og klokkeslett for migreringen.

IMAP INTERNALDATE

Dette er den tredje datoen, og den som skaper trøbbel. INTERNALDATE er en metadata lagret på IMAP-serversiden, uavhengig av meldingsinnholdet. Den representerer datoen e-posten ble levert (eller satt inn) i postboksen. Når et migrasjonsverktøy setter inn en e-post via IMAP APPEND-kommandoen, er det verktøyet selv som bestemmer hvilken verdi INTERNALDATE skal få. Og i mange tilfeller bruker verktøyene migrasjonsdatoen. Ikke originaldatoen.

Der er det det låser seg.

Hvorfor Outlook viser migrasjonsdatoen

Outlook bruker INTERNALDATE til å vise kolonnen "Mottatt". Det er standard oppførselen, og den er i tråd med IMAP-spesifikasjonen: INTERNALDATE skal representere mottaksdatoen i postboksen. I et normalt forløp (en ekte innkommende e-post) er INTERNALDATE nær datoen i Date:-hodet. De to henger naturlig sammen.

Etter en mislykket migrering peker INTERNALDATE for alle importerte e-poster mot natten mellom 14. og 15. juni 2024 (eller hva enn migrasjonsdatoen var). Outlook leser denne verdien, viser den i kolonnen "Mottatt", og resultatet er katastrofalt: 45 000 e-poster ser ut til å ha kommet inn samme kveld.

For å være presis: det første Received:-hodet (det nyeste i stabelen) påvirker også visningen i enkelte konfigurasjoner. Men INTERNALDATE er fremdeles den dominerende faktoren for "Mottatt"-kolonnen i Outlook med IMAP-synkronisering.

Workarouden "Legg til Sendt-kolonnen" i Outlook

Det første de fleste IT-administratorer gjør når de oppdager problemet, er å lete etter en klientsidebasert løsning. Og det finnes faktisk en.

I Outlook kan du endre kolonnevisningen for en mappe, slik at du erstatter (eller supplerer) "Mottatt"-kolonnen med "Dato"- eller "Sendt"-kolonnen. "Dato"-kolonnen leser direkte fra Date:-hodet, ikke fra INTERNALDATE. Siden Date:-hodet ikke ble berørt av migreringen, dukker de opprinnelige datoene opp igjen.

I Outlook (desktop, Microsoft 365-versjon) gjøres dette slik: høyreklikk på kolonnehodet i meldingslisten, velg "Visningsinnstillinger", og rediger kolonnene for å fjerne "Mottatt" og legge til "Dato". Dette kan distribueres via GPO for masseutrulling.

Greit. På papiret løser dette det visuelle problemet. I praksis er det et plaster på et skuddsår.

De konkrete begrensningene ved denne workarounden

Mobil- og webklienter

Outlook på iOS, Android og Outlook Web App (OWA) har ikke de samme tilpasningsmulighetene. Visningsendringen du rullet ut på Windows-maskiner, sprer seg ikke til disse klientene. Brukere som sjekker e-post på mobilen, fortsetter å se migrasjonsdatoen. Og i en gjennomsnittlig bedrift er det sannsynligvis halvparten av brukerne.

Søk

Outlook-søket bruker Windows Search-indeksen (eller Exchange/Microsoft 365-indeksen på serversiden). Denne indeksen bygges fra INTERNALDATE, ikke fra Date:-hodet. Hvis en bruker søker etter "e-poster fra januar 2022", returnerer søket e-poster der INTERNALDATE er i januar 2022. Ikke de der Date:-hodet er i januar 2022. Resultatet: gamle e-poster dukker ikke lenger opp i datofiltrene. Å endre visningskolonnen endrer ingenting på dette.

E-postregler

Outlook-regler ("hvis e-posten ble mottatt før...", "hvis e-posten ble mottatt etter...") bruker også INTERNALDATE. En sorterings- eller arkiveringsregel basert på datointervaller vil ikke fungere korrekt etter migrering hvis INTERNALDATE ikke er rettet.

Samsvar og eDiscovery

Dette er kanskje det mest alvorlige punktet. Samsvarsverktøy, juridisk arkivering og eDiscovery-løsninger (som Microsoft Purview) bruker INTERNALDATE som daторeferanse for juridiske forespørsler. Hvis virksomheten din har lagringsforpliktelser etter GDPR eller må svare på juridiske krav, kan korrupte INTERNALDATE-verdier skape reelle juridiske problemer. Et revisjonskrav om "alle e-poster mellom disse datoene" gir ikke riktige resultater.

Tredjepartsverktøy

CRM-systemer, ticketingverktøy, arkiveringsløsninger... alt som kobler seg til e-postserveren via IMAP eller Microsoft 365/Google Workspace-APIene, leser INTERNALDATE. Å endre Outlook-visningen retter ingenting for disse systemene.

Den eneste ekte løsningen: rett på servernivå

Sortering etter sendedato i Outlook er ikke en løsning. Det er et plaster. Den ekte rettingen må skje på nivå med serverens metadata, ikke i klientvisningen.

Konkret betyr det å rette INTERNALDATE for hver enkelt e-post slik at den samsvarer med originaldatoen i Date:-hodet. Det originale Date:-hodet er alltid til stede i meldingen (det ble ikke slettet av migreringen), noe som gjør korreksjon mulig. Det er der den reelle datoinformasjonen finnes.

På Google Workspace eksponerer Gmail-APIet en internalDate-parameter som gir direkte tilgang til denne metadataen. På Microsoft 365 er mekanismen annerledes, men forventet resultat er det samme. På en standard IMAP-server tillater standarden at datoen spesifiseres ved innsetting av en melding.

I praksis er det å gjennomføre denne operasjonen på titusenvis av e-poster i produksjon, uten datatap, uten duplikater, uten å bryte trådstrukturer eller etiketter, med håndtering av kanttilfeller (S/MIME-signerte meldinger, komplekse MIME-strukturer, ikke-ASCII-koding ifølge RFC 2047, store vedlegg)... en helt annen sak. Et skript som fungerer på 50 teste-poster, holder ikke til en postboks med 40 000 meldinger. Håndtering av 429-feil (API-kvote overskredet), nettverkstimeouts klokken 02 om natten, meldinger med MIME-struktur som allerede er delvis ødelagt etter migrering... alt dette krever seriøs ingeniørkompetanse.

Det er nøyaktig dette Redate.io gjør. Det proprietære korreksjonsverktøyet analyserer hodekjeden i hver enkelt e-post, identifiserer den pålitelige originaldatoen, og anvender en målrettet metadatakorreksjon uten å røre meldingsinnholdet. Hver korrigert e-post verifiseres individuelt. Originalene bevares i en sikkerhetskopieringsmappe i 30 dager, noe som gjør rollback mulig når som helst. Det er noe et hjemmelaget skript aldri tilbyr.

Identifisere det ansvarlige migrasjonsverktøyet

Problemet manifesterer seg på samme måte uavhengig av hvilken migrasjon som ble brukt, men detaljene varierer etter verktøy. BitTitan MigrationWiz, CloudM, imapsync og GSMMO har hver sin signatur i Received:-hodene de injiserer. Redate.ios analysepipeline opprettholder en mønsterbase over hundrevis av kjente migrasjonsverktøysignaturer for å skille migrasjonshodet fra resten av den legitime transittjeden.

Vet du ikke hvilket verktøy som ble brukt for migreringen? (Det skjer, særlig når du overtar et miljø fra en annen MSP.) Det gratis skannet fra Redate.io identifiserer berørte postbokser og gir et estimat over volumet som må rettes, uten noen form for forpliktelse.

For spesifikke scenarioer finnes det detaljerte veiledninger: rette imapsync-datoer i Outlook, rette BitTitan-datoer i Outlook, eller rette CloudM-datoer i Outlook.

Hva gjør du nå

Leser du dette etter en migrering, er den gode nyheten at det originale Date:-hodet er intakt i hver eneste e-post. Den reelle datoinformasjonen er der, i hver melding. Problemet ligger i metadataene, ikke i innholdet. Og metadata kan rettes.

Du kan også lese artikkelen om IMAP INTERNALDATE: hvorfor datoer ødelegges for å gå dypere inn i mekanikken bak problemet, eller den fullstendige guiden om feil datoer i Outlook etter migrering for en oversikt over de ulike scenarioene.

Klar til å rette datoene i postboksene dine? Start et gratis skann på Redate.io for å identifisere berørte e-poster og estimere volumet før noen korreksjon iverksettes.