Outlook: mottaget datum IMAP vs skickat datum

Symptomet alla känner igen

Du har precis avslutat en IMAP-migrering till Microsoft 365 eller Google Workspace. Måndag morgon rullar ärendena in: "Alla mina e-postmeddelanden har samma datum", "Min historik är förstörd", "Jag hittar ingenting i min inkorg". Du öppnar Outlook och ser det med egna ögon: tusentals e-postmeddelanden visar datumet från förra helgen. Inte det datum de skickades. Datumet då migreringen ägde rum.

Det här är inte ett Outlook-fel. Det är en direkt konsekvens av hur IMAP-protokollet fungerar och hur migreringsverktyg är konstruerade. Men för att förstå varför behöver man titta under huven.

Tre datum i ett enda e-postmeddelande

Ett e-postmeddelande är mer komplext än det verkar. Rubriker, meddelandetext, bilagor... och flera separata tidsstämplar som samexisterar. (Om du någonsin försökt läsa råa e-postrubriker vet du att det inte precis är strandläsning.)

Date:-rubriken (RFC 2822)

Det här är datumet som avsändaren lade in i meddelandet vid sändningstillfället. Definierat av RFC 2822 ser det ut så här:

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

Den här rubriken är ingjuten i meddelandets massa. Den ändras aldrig, om man inte modifierar meddelandets råinnehåll direkt. Det är "skickat datum" i ordets striktaste mening.

Received:-rubriken (läggs till vid varje nätverkshopp)

Varje server som hanterar ett e-postmeddelande under transporten lägger till en Received:-rubrik längst upp i meddelandet, med sitt eget datum. Ett e-postmeddelande som passerar tre servrar samlar alltså på sig tre Received:-rubriker. Den senaste ligger alltid överst. Det ser ut ungefär så här:

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 ett migreringsverktyg som BitTitan MigrationWiz, CloudM, imapsync eller GSMMO flyttar ett e-postmeddelande från en källserver till en målserver beter det sig också som ett "nätverkshopp". Det injicerar en ny Received:-rubrik längst upp i stacken, med migreringens datum och tid.

IMAP INTERNALDATE

Det här är det tredje datumet, och det är det som ställer till problem. INTERNALDATE är metadata som lagras på IMAP-servern, oberoende av meddelandets innehåll. Det representerar datumet då e-postmeddelandet levererades (eller infogades) i postlådan. När ett migreringsverktyg infogar ett meddelande är det verktyget självt som bestämmer vilket värde INTERNALDATE ska få. Och i många fall använder verktygen tidpunkten för migreringen. Inte det ursprungliga datumet.

Det är där allt går snett.

Varför Outlook visar migreringsdatumet

Outlook använder INTERNALDATE för att visa kolumnen "Mottaget". Det är standardbeteendet, och det är konsekvent med IMAP-specifikationen: INTERNALDATE är tänkt att representera det datum meddelandet togs emot i postlådan. I ett normalt flöde (ett riktigt e-postmeddelande som anländer) ligger INTERNALDATE nära datumet i Date:-rubriken. De två stämmer överens.

Efter en misslyckad migrering pekar INTERNALDATE för alla importerade e-postmeddelanden mot natten mellan den 14 och 15 juni 2024 (eller vilket datum migreringen skedde). Outlook läser det värdet, visar det i kolumnen "Mottaget", och resultatet är förödande: 45 000 e-postmeddelanden verkar ha tagits emot samma kväll.

För att vara precis påverkar den första Received:-rubriken (den senaste i stacken) också visningen i vissa konfigurationer. Men INTERNALDATE är fortfarande den avgörande faktorn för kolumnen "Mottaget" i Outlook i synkroniserat IMAP-läge.

Lösningen "Lägg till kolumnen Skickat" i Outlook

Det första de flesta IT-admins gör när de upptäcker problemet är att leta efter en klientsidig lösning. Och det finns faktiskt en.

I Outlook kan man ändra kolumnvisningen för en mapp och ersätta (eller komplettera) kolumnen "Mottaget" med kolumnen "Datum" eller "Skickat". Kolumnen "Datum" läser direkt från meddelandets Date:-rubrik, inte från INTERNALDATE. Eftersom Date:-rubriken inte berördes av migreringen dyker de ursprungliga datumen upp igen.

Så här gör du i Outlook (skrivbordsapp, Microsoft 365-versionen): högerklicka på kolumnrubriken i meddelandelistan, välj "Visningsinställningar", och ändra kolumnerna för att ta bort "Mottaget" och lägga till "Datum". Det går att distribuera via GPO för storskalig utrullning.

På pappret löser det det visuella problemet. I praktiken är det ett plåster på en pulsåder.

De konkreta begränsningarna med den här lösningen

Mobila och webbaserade klienter

Outlook på iOS, Android och Outlook Web App (OWA) saknar samma anpassningsmöjligheter. Visningsändringen du distribuerade på Windows-datorer sprids inte vidare. Användare som läser sin e-post i telefonen fortsätter se migreringsdatumet. I ett medelstort företag är det troligtvis hälften av alla användare.

Sökfunktionen

Outlooks sökfunktion använder Windows Search-indexet (eller Exchange/Microsoft 365-indexet på serversidan). Det indexet byggs från INTERNALDATE, inte från Date:-rubriken. Om en användare söker efter "e-post från januari 2022" returnerar sökningen meddelanden vars INTERNALDATE är i januari 2022. Inte de vars Date:-rubrik är i januari 2022. Gamla e-postmeddelanden dyker alltså inte upp i datumfilter. Att byta visningskolumn ändrar ingenting på det.

E-postregler

Outlooks regler ("om e-postmeddelandet togs emot före...", "om e-postmeddelandet togs emot efter...") använder också INTERNALDATE. En sorterings- eller arkiveringsregel baserad på datumintervall fungerar inte längre korrekt efter migrering om INTERNALDATE inte har korrigerats.

Efterlevnad och eDiscovery

Det här är kanske den allvarligaste punkten. Verktyg för efterlevnad, juridisk arkivering och eDiscovery (Microsoft Purview till exempel) använder INTERNALDATE som datumsreferens för juridiska förfrågningar. Om ditt företag har krav på datalagring eller behöver svara på discovery-begäranden kan korrupta INTERNALDATE-värden skapa verkliga juridiska problem under en revision. En förfrågan om "alla e-postmeddelanden mellan dessa datum" returnerar helt enkelt inte rätt resultat.

Tredjepartsverktyg

CRM-system, ärendehanteringsverktyg, arkivsystem... allt som ansluter till din e-postserver via IMAP eller Microsoft 365/Google Workspace API:er läser INTERNALDATE. Att ändra Outlook-vyn korrigerar ingenting för dessa system.

Den enda riktiga lösningen: korrigera på servernivå

Att sortera på skickat datum i Outlook är ingen lösning. Det är ett plåster. Den riktiga korrigeringen måste ske på metadatanivå i servern, inte i klientvyn.

Konkret innebär det att korrigera INTERNALDATE för varje e-postmeddelande så att den matchar det ursprungliga datumet i Date:-rubriken. Den ursprungliga Date:-rubriken finns alltid kvar i meddelandet (den raderades inte av migreringen), vilket gör korrigeringen möjlig. Det är där den verkliga datuminformationen finns.

På Google Workspace exponerar Gmail API en internalDate-parameter som ger direkt åtkomst till den metadata. På Microsoft 365 är mekanismen annorlunda men slutresultatet är detsamma. På en standard-IMAP-server tillåter protokollet att datumet anges när ett meddelande infogas.

I praktiken är det en helt annan sak att utföra den här operationen på tiotusentals produktionse-postmeddelanden utan dataförlust, utan dubbletter, utan att förstöra konversationstrådar eller etiketter, och med hantering av edge cases (S/MIME-signerade meddelanden, komplexa MIME-strukturer, icke-ASCII-kodningar enligt RFC 2047, stora bilagor). Ett skript som fungerar på 50 testmeddelanden håller inte för en postlåda med 40 000 meddelanden. Hantering av 429-fel (API-kvot överskriden), nätverkstimeouts klockan 02:00 under en migreringsbatch, meddelanden med MIME-strukturer som redan är delvis korrupta efter migreringen... allt det kräver seriös ingenjörskonst.

Det är precis det Redate.io gör. Den proprietära korrigeringsmotorn analyserar rubrikkedjan i varje e-postmeddelande, identifierar det tillförlitliga ursprungliga datumet, och tillämpar en riktad metadatakorrigering utan att röra meddelandeinnehållet. Varje korrigerat e-postmeddelande verifieras individuellt. Originalen sparas i en säkerhetskopieringsmapp i 30 dagar, vilket gör det möjligt att återställa när som helst. Något ett hemmagjort skript aldrig erbjuder.

Identifiera vilket migreringsverktyg som orsakat problemet

Problemet visar sig på samma sätt oavsett varifrån migreringen kom, men detaljerna varierar beroende på vilket verktyg som användes. BitTitan MigrationWiz, CloudM, imapsync och GSMMO har var sin signatur i de Received:-rubriker de injicerar. Redate.io:s analyspipeline underhåller en matchningsdatabas över hundratals signaturer från kända migreringsverktyg, för att skilja migreringsrubriken från resten av den legitima transitkedjan.

Om du inte vet vilket verktyg som användes för din migrering (det händer, särskilt när man tar över en miljö efter en annan MSP) identifierar Redate.io:s gratis skanning de påverkade postlådorna och ger en uppskattning av volymen som behöver korrigeras, innan du binder dig till något.

För specifika sammanhang finns detaljerade guider: åtgärda imapsync-datum i Outlook, åtgärda BitTitan-datum i Outlook, och åtgärda CloudM-datum i Outlook.

Vad gör du nu?

Om du läser det här efter en migrering är den goda nyheten att den ursprungliga Date:-rubriken är intakt i varje e-postmeddelande. Den verkliga datuminformationen finns där, i varje meddelande. Problemet ligger i metadata, inte i innehållet. Och metadata går att korrigera.

Du kan också läsa artikeln IMAP INTERNALDATE: varför datum går sönder för att gå djupare in på mekaniken bakom problemet, eller den kompletta guiden om felaktiga datum i Outlook efter migrering för en övergripande bild av olika scenarion.

Redo att korrigera datumen i dina postlådor? Kör en gratis skanning på Redate.io för att identifiera påverkade e-postmeddelanden och uppskatta volymen innan någon korrigering görs.