Nya Outlook: fel datum efter migrering, verkliga orsaker

Två Outlook, två olika beteenden med samma e-post

Om du nyligen migrerat brevlådor till Microsoft 365 och vissa användare klagar på att alla gamla e-postmeddelanden visar samma datum (migreringsdatumet), kanske du lagt märke till något märkligt: användare med klassiska Outlook ser ibland rätt datum i läsfönstret, medan de som kör nya Outlook för Windows konsekvent ser migreringsdatumet. Samma brevlåda. Samma e-post. Olika resultat.

Det är inte en bugg i strikt mening. Det är ett arkitekturbeslut med direkta konsekvenser för hur datum visas efter en IMAP-migrering. För att förstå vad som händer behöver man gå in på detaljnivå kring e-postheadrar och IMAP-protokollet, inte precis lättsam läsning, men det förklarar varför ingen åtgärd på klientsidan räcker för att lösa problemet.

IMAP INTERNALDATE: den verkliga boven

När ett e-postmeddelande lagras på en IMAP-server finns det två typer av datum som existerar parallellt och inte ska blandas ihop.

Det första är Date:-headern, definierad av RFC 2822. Det är datumet som är skrivet i själva meddelandet, det som avsändaren satte när e-posten skickades. Det ingår i meddelandets kropp och ändras aldrig, oavsett vilken väg e-posten sedan tar.

Det andra är INTERNALDATE, ett servermetadata utanför meddelandet som hanteras av IMAP-servern. Det är datumet då servern registrerade meddelandet. Vid en normal migrering bevarar seriösa verktyg det ursprungliga INTERNALDATE. Men vid en felkonfigurerad migrering, eller med verktyg som inte hanterar den här metadatan korrekt, återställs INTERNALDATE till dagens datum vid migreringstillfället. Resultatet: alla migrerade e-postmeddelanden bär samma ankomstdatum i serverns ögon.

(Har du någon gång tittat i loggarna för imapsync eller MigrationWiz vet du att det finns specifika alternativ för att försöka bevara INTERNALDATE. De fungerar inte alltid, och vissa målservrar vägrar att respektera dem.)

Klassiska Outlook: hur det läser datum

Klassiska Outlook, alltså de lokalt installerade COM-versionerna (Outlook 2016, 2019, 2021 och Microsoft 365 Apps-skrivbordsklienten), använder en lite mer komplex mekanism för att bestämma vilket datum som ska visas i meddelandelistan.

För e-post i mappen Skickat förlitar det sig på Date:-headern. För mottagen e-post prioriterar det serverns INTERNALDATE, men i vissa sammanhang (framför allt när OST-cachen är inblandad eller vid första visning i läsfönstret) kan det även läsa Received:-headerkedjan för att rekonstruera ett ungefärligt ursprungsdatum.

Det är därför man ser det inkonsekventa beteendet: klassiska Outlook kan ibland visa rätt datum i läsfönstret, för att det läser den ursprungliga Date:-headern för detaljvisningen, även om e-postlistan i sig använder det korrupta INTERNALDATE. Men det är inte tillförlitligt och det rättar ingenting. Sorteringen är fortfarande trasig, och datumbaserade sökningar ger fortfarande fel resultat.

Nya Outlook: en radikalt annorlunda arkitektur

Nya Outlook för Windows, som rullats ut successivt sedan slutet av 2023, är inte längre ett COM-program. Det är i grunden en Progressive Web App (PWA) baserad på samma kodbas som Outlook på webben (OWA). Den ombyggnaden har djupgående konsekvenser.

Nya Outlook delegerar all datumvisning till Microsoft 365 API:et. Det läser inte Received:-headrar, gräver inte i headerkedjan för att hitta ett ursprungsdatum, och gör inga rekonstruktionsförsök på klientsidan. Det visar helt enkelt vad servern returnerar: INTERNALDATE.

Resultatet: om INTERNALDATE korrupterades under migreringen tvekar inte nya Outlook. Det visar migreringsdatumet för varje berörd e-post, utan undantag och utan nyanser. Det är ett mer konsekvent och förutsägbart beteende än klassiska Outlook, men det gör migreringsproblemet omedelbart synligt och omöjligt att ignorera.

En admin som migrerar 300 brevlådor en fredagskväll kommer att upptäcka på måndag morgon att alla användare på nya Outlook ser hela sina arkiv daterade till föregående helg. Supportärendena trillar in snabbt.

Varför inga klientsidiga lösningar fungerar

Många admins provar klientbaserade lösningar innan de förstår att problemet sitter i serverdatan. Här är de vanligaste försöken, och varför de misslyckas.

Sortera på "Skickat datum" istället för "Mottaget datum"

Sortering på skickat datum i Outlook bygger på meddelandets Date:-header, som är intakt. Så ja, den sorteringen kan fungera. Men det är ett plåster, inte en lösning. Datumbaserade sökningar är fortfarande trasiga. Regler baserade på datum är fortfarande oanvändbara. Och framför allt måste användaren manuellt konfigurera om varje mapp och varje brevlåda. På 300 brevlådor är det orealistiskt. Sortering på avsändningsdatum löser ingenting, och slutanvändarna förstår inte varför de ska behöva ändra sina vanor.

Tömma Outlook-cachen eller återskapa profilen

Det påverkar inte INTERNALDATE på servern. Efter att profilen skapats på nytt synkroniserar Outlook om e-posten från servern och hämtar exakt samma korrupta metadata. Cachen är inte problemet.

Använda OWA istället

OWA och nya Outlook delar samma databas. Om INTERNALDATE är korrupt på Exchange Online-servern visar OWA exakt samma felaktiga datum. Att byta klient ändrar inte datan.

Problemet sitter på servern, i varje meddelandets metadata. Inga åtgärder på klientsidan kan rätta data som lagras på serversidan.

Fällan med Received-headrar: varför de komplicerar allt

När ett migreringsverktyg kopierar ett e-postmeddelande från en server till en annan via IMAP lägger målservern automatiskt till en Received:-header överst i kedjan, med datum och tid för infogandet. Det är det normala beteendet hos RFC-kompatibla SMTP- och IMAP-servrar.

Dessa headrar ackumuleras i omvänd ordning jämfört med e-postens väg. Den senaste är överst. Vissa e-postklienter läser den första Received:-headern för att uppskatta ankomstdatumet, vilket ger migreringsdatumet istället för det ursprungliga datumet.

Det här beteendet gäller inte bara ett enda verktyg. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, och till och med en manuell IMAP-kopiering mellan två Thunderbird-klienter ger alla samma resultat. Den ursprungliga Date:-headern är intakt i meddelandet. Det är exakt det som gör en korrektion tekniskt möjlig. Men INTERNALDATE är en separat metadata som hanteras av servern och kan inte rättas genom att enkelt manipulera meddelandets headrar på klientsidan.

Artikeln om IMAP INTERNALDATE och trasiga datum går djupare in på hur den här metadatan hanteras beroende på server.

Vilka migreringsverktyg orsakar det här problemet i Microsoft 365

Frågan återkommer ofta: orsakar alla migreringsverktyg det här problemet?

Det korta svaret är att det beror på konfigurationen och målplattformen. På Exchange Online / Microsoft 365 är servern särskilt strikt i sin hantering av INTERNALDATE. Även verktyg som försöker bevara den misslyckas ibland, eftersom Graph API och EWS (Exchange Web Services) beter sig olika beroende på vilken infogningsväg som används.

BitTitan MigrationWiz är ett av de vanligaste verktygen för migreringar till Microsoft 365, och det är också ett av dem vars datumproblem är bäst dokumenterade. Sidan åtgärda BitTitan-migreringsdatum i Microsoft 365 tar upp de specifika konfigurationer man bör hålla koll på. CloudM och imapsync har sina egna särdrag, dokumenterade på åtgärda CloudM-migreringsdatum i Microsoft 365 respektive åtgärda imapsync-migreringsdatum i Microsoft 365.

Gemensamt för alla dessa verktyg: den ursprungliga Date:-headern överlever migreringen. Det är grunden för att en korrektion är möjlig.

Varför ett eget skript är en dålig idé här

Att förstå problemet ger ibland illusionen att lösningen är enkel. Det är den inte, inte i produktionsskala.

Att ändra metadata för e-postmeddelanden lagrade på Exchange Online är inte trivialt. Microsofts Graph API har strikta hastighetsbegränsningar (429 Too Many Requests vid ett nattbatch dyker upp snabbt). Hanteringen av S/MIME-signerade eller PGP-krypterade e-postmeddelanden kräver särskild omsorg för att inte ogiltiga signaturerna. Multipart-strukturer med stora bilagor lägger till begränsningar kring nätverkstimeouts. Och framför allt: hur verifierar du, e-post för e-post, att korrektionen fungerat utan att ändra innehåll eller bilagor?

Ett skript som fungerar fint på 50 testmeddelanden beter sig inte likadant på en brevlåda med 40 000 meddelanden och 8 års historik. Sannolikheten att ett gränsfall går sönder ökar med varje ytterligare tusental meddelanden. Och utan återställningsmekanism lämnar ett fel mitt i körningen brevlådan i ett inkonsekvent tillstånd.

Se även: korrigera e-postdatum efter Microsoft 365-migrering för en fullständig genomgång av tillgängliga alternativ.

Vad Redate.io faktiskt gör

Varje användare loggar in med sitt eget Microsoft-konto, och Redate.io öppnar just den e-postlådan med den åtkomst inloggningen ger. Redate.io genomsöker e-postlådan gratis efter e-postmeddelanden med felaktiga datum, och applicerar sedan ett proprietärt korrigeringsverktyg på de identifierade meddelandena. Den flerstegsanalys som genomförs matchar mot hundratals kända migreringsverktygs signaturer, utför RFC-kompatibilitetsvalidering, och analyserar headerkedjan för att rekonstruera korrekta datummetadata.

Varje korrigerat e-postmeddelande verifieras individuellt. Redate.io tar aldrig bort originalen. De ligger kvar i en synlig mapp i din egen e-postlåda tills du själv raderar dem. Prismodellen är ett engångsbelopp per brevlåda, utan prenumeration.

Nya Outlook visar sedan rätt datum, för att serverdatan är rättad, inte dold.

Har du drabbade brevlådor i nya Outlook? Starta en gratis skanning på Redate.io för att se exakt hur många e-postmeddelanden som berörs innan du bestämmer hur du vill gå vidare.