Outlook: modtagelsesdato IMAP vs afsendelsesdato

Det symptom alle kender

Du har lige afsluttet en IMAP-migrering til Microsoft 365 eller Google Workspace. Mandag morgen ruller tickets ind: "Alle mine e-mails har samme dato", "Min historik er ødelagt", "Jeg kan ikke finde noget i min indbakke". Du åbner Outlook, og der er det: tusindvis af e-mails med datoen fra weekenden. Ikke den dato, de blev sendt. Datoen for selve migreringen.

Det er ikke en Outlook-fejl. Det er en direkte konsekvens af, hvordan IMAP-protokollen og migreringsværktøjer fungerer. Men for at forstå hvorfor, skal vi åbne motorhjelmen.

Tre datoer i én e-mail

En e-mail er mere kompleks, end den ser ud. Header, beskedindhold, vedhæftede filer... og flere forskellige tidsstempler, der lever side om side. (Og hvis du nogensinde har prøvet at læse rå e-mailheadere, ved du, at det ikke ligefrem er strandlæsning.)

Date:-headeren (RFC 2822)

Det er den dato, afsenderen satte i beskeden ved afsendelsen. Defineret i RFC 2822 ser den sådan ud:

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

Denne header er støbt ind i selve beskedindholdet. Den ændres aldrig, medmindre nogen redigerer beskedets råindhold direkte. Det er "afsendelsesdatoen" i streng forstand.

Received:-headeren (tilføjet ved hvert netværkshop)

Hver server, der rører en e-mail undervejs, tilføjer en Received:-header øverst i beskeden med sit eget tidsstempel. En e-mail, der passerer tre servere, opsamler altså tre Received:-headere. Den nyeste er altid øverst. Det ser nogenlunde sådan her ud:

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 migreringsværktøj som BitTitan MigrationWiz, CloudM, imapsync eller GSMMO flytter en e-mail fra en kildeserver til en destinationsserver, opfører det sig selv som et "netværkshop". Det injicerer en ny Received:-header øverst i stakken med migrationsdato og -tidspunkt.

IMAP INTERNALDATE

Det er den tredje dato, og den er problemet. INTERNALDATE er en metadata-værdi gemt på IMAP-serveren, uafhængig af beskedindholdet. Den repræsenterer den dato, e-mailen blev leveret (eller indsat) i postkassen. Når et migreringsværktøj indsætter en e-mail via IMAP APPEND-kommandoen, er det værktøjet selv, der bestemmer, hvilken INTERNALDATE-værdi der bruges. Og i mange tilfælde bruger værktøjerne tidspunktet for selve migreringen. Ikke den originale dato.

Det er her, det hele kører af sporet.

Hvorfor Outlook viser migrationsdatoen

Outlook bruger INTERNALDATE til at vise kolonnen "Modtaget". Det er standardadfærden og er i overensstemmelse med IMAP-specifikationen: INTERNALDATE er beregnet til at repræsentere leveringsdatoen i postkassen. I et normalt flow (en reel indgående e-mail) ligger INTERNALDATE tæt på datoen i Date:-headeren. De to er konsistente.

Efter en mislykket migrering peger INTERNALDATE for alle importerede e-mails på natten mellem den 14. og 15. juni 2024 (eller hvad migreringsdatoen end var). Outlook læser denneværdi, viser den i kolonnen "Modtaget", og resultatet er katastrofalt: 45.000 e-mails ser ud til at være modtaget samme aften.

For at være præcis: den første Received:-header (den nyeste i stakken) påvirker også visningen i visse konfigurationer. Men INTERNALDATE er stadig den primære faktor for Outlooks "Modtaget"-kolonne i synkroniseret IMAP-tilstand.

Løsningen "Tilføj kolonnen Sendt" i Outlook

Det første, de fleste IT-admins gør, når de opdager problemet, er at lede efter en klient-side-løsning. Og der findes faktisk én.

I Outlook kan man tilpasse kolonnevisningen i en mappe for at erstatte (eller supplere) kolonnen "Modtaget" med kolonnen "Dato" eller "Sendt". Kolonnen "Dato" læser direkte fra beskedets Date:-header, ikke fra INTERNALDATE. Da Date:-headeren ikke er blevet rørt af migreringen, dukker de originale datoer op igen.

Sådan gør du i Outlook (desktop, Microsoft 365-version): højreklik på kolonne-headeren i beskedlisten, vælg "Visningsindstillinger", og rediger kolonnerne for at fjerne "Modtaget" og tilføje "Dato". Det kan rulles ud via GPO til masseimplementering.

Fint nok. På papiret løser det det visuelle problem. I praksis er det et plaster på en pulsåre.

De konkrete begrænsninger ved denne løsning

Mobil- og webklienter

Outlook på iOS, Android og Outlook Web App (OWA) har ikke de samme tilpasningsmuligheder. Den visningsændring, du har rullet ud på Windows-computerne, slår ikke igennem her. Dine brugere, der tjekker e-mail på telefonen, ser stadig migrationsdatoen. Og i en mellemstor virksomhed er det sandsynligvis halvdelen af brugerne.

Søgning

Outlook-søgning bruger Windows Search-indekset (eller Exchange/Microsoft 365-indekset på serversiden). Det indeks er bygget op fra INTERNALDATE, ikke fra Date:-headeren. Hvis en bruger søger efter "e-mails fra januar 2022", returnerer søgningen e-mails, hvis INTERNALDATE er i januar 2022. Ikke dem, hvis Date:-header er i januar 2022. Resultatet: gamle e-mails dukker ikke op i datofiltrene mere. At ændre kolonnevisningen ændrer intet her.

E-mailregler

Outlooks regler ("hvis e-mailen er modtaget før...", "hvis e-mailen er modtaget efter...") bruger også INTERNALDATE. En sorterings- eller arkiveringsregel baseret på datointerval vil ikke fungere korrekt efter migrering, hvis INTERNALDATE ikke er rettet.

Compliance og eDiscovery

Det er måske det mest alvorlige punkt. Compliance-værktøjer, juridisk arkivering og eDiscovery (Microsoft Purview, for eksempel) bruger INTERNALDATE som datoreference i juridiske forespørgsler. Hvis din virksomhed har opbevaringspligter eller skal svare på discovery-anmodninger, kan korrupte INTERNALDATE-værdier skabe reelle juridiske problemer. En revision, der beder om "alle e-mails mellem den og den dato", returnerer ikke de rigtige resultater. GDPR-dokumentation bliver upålidelig. Det er ikke en teoretisk risiko.

Tredjepartsværktøjer

CRM-systemer, ticketing-værktøjer, arkiveringsløsninger... alt, der forbinder sig til din mailserver via IMAP eller Microsoft 365/Google Workspace API'erne, læser INTERNALDATE. At ændre Outlook-visningen retter ingenting for disse systemer.

Den eneste rigtige løsning: ret det på serverniveau

Sortering efter afsendelsesdato i Outlook er ikke en løsning. Det er et plaster. Den rigtige rettelse skal ske på serverens metadata-niveau, ikke i klientvisningen.

Konkret betyder det at rette INTERNALDATE for hver enkelt e-mail, så den svarer til den originale dato fra Date:-headeren. Den originale Date:-header er altid til stede i beskeden (den er ikke blevet slettet af migreringen), hvilket gør rettelsen mulig. Det er der, den reelle datoinformation ligger.

På Google Workspace eksponerer Gmail API en internalDate-parameter, der giver direkte adgang til denne metadata. På Microsoft 365 er mekanismen anderledes, men det forventede resultat er det samme. På en standard IMAP-server tillader specifikationen, at datoen kan specificeres ved indsætning af en besked.

I praksis er det en helt anden sag at udføre denne operation på titusindvis af e-mails i et produktionsmiljø uden datatab, uden dubletter, uden at ødelægge tråde eller labels, og med korrekt håndtering af kanttilfælde: S/MIME-signerede beskeder, komplekse MIME-strukturer, ikke-ASCII-encodinger jf. RFC 2047, store vedhæftede filer... Et script, der fungerer på 50 teste-mails, holder ikke til en postkasse med 40.000 beskeder. Håndtering af 429-fejl (API-kvote overskredet), netværkstimeouts klokken 2 om natten, beskeder med delvist ødelagt MIME-struktur efter migrering - alt det kræver seriøs ingeniørkunst.

Det er præcis, hvad Redate.io gør. Den proprietære korrektionsmotor analyserer header-kæden i hver enkelt e-mail, identificerer den pålidelige originaldato og anvender en målrettet metadata-korrektion uden at røre beskedindholdet. Hver rettet e-mail verificeres individuelt. Originalerne gemmes i en backup-mappe i 30 dage, så rollback er mulig til enhver tid. Det tilbyder et hjemmelavet script aldrig.

Identificer det ansvarlige migreringsværktøj

Problemet manifesterer sig på samme måde uanset migreringskilden, men detaljerne varierer afhængigt af det brugte værktøj. BitTitan MigrationWiz, CloudM, imapsync og GSMMO har alle deres eget fingeraftryk i de Received:-headere, de injicerer. Redate.io's analysepipeline vedligeholder en database med hundredvis af kendte migreringsværktøjs-signaturer for at skelne migrations-headeren fra den legitime transitkæde.

Hvis du ikke ved, hvilket værktøj der blev brugt til din migrering (det sker, især når du overtager et miljø efter en anden MSP), identificerer Redate.io's gratis scan de berørte postkasser og giver et estimat over det volumen, der skal rettes, inden du forpligter dig til noget.

Til specifikke scenarier findes der detaljerede guides: ret imapsync-migreringsdatoer i Outlook, ret BitTitan-migreringsdatoer i Outlook eller ret CloudM-migreringsdatoer i Outlook.

Hvad gør du nu

Hvis du læser denne artikel efter en migrering, er den gode nyhed, at den originale Date:-header er intakt i hver af dine e-mails. Den reelle datoinformation er der, til stede i hver enkelt besked. Problemet ligger i metadata, ikke i indholdet. Og metadata kan rettes.

Du kan også læse artiklen IMAP INTERNALDATE: hvorfor datoer går i stykker for at gå dybere ned i mekanikken bag problemet, eller den komplette guide til forkerte datoer i Outlook efter migrering for et samlet overblik over de typiske tilfælde.

Klar til at rette datoerne i dine postkasser? Start en gratis scanning på Redate.io for at identificere de berørte e-mails og estimere volumenet inden nogen korrektion foretages.