iCloud till Office 365-migrering: felaktiga e-postdatum

En migrering som systematiskt förstör datum

Du har precis avslutat flytten av din iCloud-post till Office 365. E-postmeddelandena finns på plats, mapparna ser rätt ut, allt verkar perfekt. Måndag morgon kommer den första klagomålet: "Alla mina gamla e-postmeddelanden visar dagens datum." Sedan ett till. Sedan tio.

Det är inte ett isolerat fel. Migrering från iCloud Mail till Office 365 är ett av de mest dokumenterade scenarierna för korruption av e-postdatum, av tekniska skäl som rör Apple Mails beteende, IMAP-protokollet och hur Microsoft 365 hanterar inkommande meddelanden.

Varför iCloud till Office 365 förstör datum

För att förstå problemet behöver du skilja på tre saker som många (även erfarna IT-administratörer) blandar ihop: Date:-headern, IMAP INTERNALDATE och filens skapelsedatum.

Date:-headern (RFC 2822)

Varje e-postmeddelande innehåller en Date:-header som anger när meddelandet skickades. Den headern är inbäddad i meddelandets råtext och förändras aldrig, i teorin. Det är det "ursprungliga" datumet i ordets strikta bemärkelse.

IMAP INTERNALDATE

IMAP-protokollet (definierat i RFC 3501) kopplar en separat metadatapost till varje meddelande, kallad INTERNALDATE. Det är det värdet som de flesta e-postklienter använder för att sortera och visa meddelanden i inkorgen, inte Date:-headern. Outlook förlitar sig särskilt starkt på INTERNALDATE för visning och sortering.

Problemet? När ett migreringsverktyg kopierar ett e-postmeddelande från en IMAP-server till en annan borde det idealt bevara INTERNALDATE. I praktiken är det inte alltid vad som händer.

Apple Mails särskilda beteende

Apple Mail använder ibland filens skapelsedatum på serversidan som referens för INTERNALDATE när det synkroniserar meddelanden från iCloud. Det är inte ett fel i strikt bemärkelse, utan en tolkning av IMAP-specifikationen som skiljer sig från vad andra klienter gör. (Om du någonsin försökt felsöka ett INTERNALDATE-problem genom att läsa de råa IMAP-RFC:erna, vet du att specifikationen lämnar ganska stort tolkningsutrymme på just den punkten.)

Resultatet: när du exporterar eller migrerar från iCloud via Apple Mail kan INTERNALDATE på meddelandena redan vara felaktiga innan de ens når Office 365.

Tre migreringsmetoder från iCloud och deras fallgropar

Direkt IMAP-migrering

Den vanligaste metoden är att konfigurera iCloud som IMAP-källa och Office 365 som destination, sedan använda ett migreringsverktyg (imapsync, MigrationWiz eller ett egenbyggt verktyg). Verktyget ansluter till båda servrarna och kopierar meddelandena.

Problemet här är tvåfaldigt. Apples IMAP-servrar har hastighetsgränser som tvingar verktyg att pausa, vilket skapar tidsfönster där anslutningar stängs och öppnas på nytt, något som kan generera felaktiga INTERNALDATE. Dessutom får varje meddelande som kopieras till Exchange Online som standard ett insättningsdatum som motsvarar migreringstidpunkten, om inte verktyget explicit skickar med det ursprungliga INTERNALDATE i infogningskommandot.

Vissa verktyg hanterar det korrekt. Andra gör det inte konsekvent. På en brevlåda med 40 000 meddelanden innebär till och med en felfrekvens på 2 % att 800 e-postmeddelanden har fel datum.

För migreringar via imapsync, se även: åtgärda imapsync-migreringsdatum i Microsoft 365.

Export som .mbox eller .eml och sedan import

Vissa användare exporterar sina iCloud-meddelanden via Apple Mail i .mbox-format och försöker sedan importera dem i Outlook. Det är en hantverksmässig metod som ger varierande resultat.

.mbox-formatet kodar e-postmeddelanden som en sekvens av textmeddelanden. Datumen finns i de enskilda Date:-headrarna, men separationsraden mellan meddelanden ("From ") innehåller ett datum som vissa importverktyg kan tolka som skapelsedatum. Outlook, när det importerar en .mbox konverterad till .pst, använder ibland det separationsdatumet istället för meddelandets egna Date:-header.

Dra-och-släpp via Outlook

Det här är metoden som ställer till störst skada. En användare konfigurerar båda kontona i Outlook (iCloud och Office 365), och drar sedan sina meddelanden från en mapp till en annan. Det verkar enkelt. Det är en katastrof för datumen.

När Outlook flyttar ett meddelande via dra-och-släpp mellan två IMAP-konton skapar det i praktiken en ny .EML-fil, infogar den i destinationskontot och raderar originalet. Den nya filen ärver Windows-filens skapelsedatum, alltså exakt tidpunkten för dra-och-släpp-operationen. Den ursprungliga Date:-headern finns fortfarande kvar i meddelandets brödtext, men INTERNALDATE som sparas på Exchange Online-servern motsvarar tidpunkten för operationen. Outlook visar sedan det migreringsdatumet för alla flyttade meddelanden.

För att vara exakt: det här beteendet varierar beroende på Outlook-version. Sedan Outlook-uppdateringen hösten 2023 har beteendet förbättrats något för vissa scenarier, men dra-och-släpp mellan konton är fortfarande en dokumenterad källa till datumkorruption.

Vad Office 365 och Outlook faktiskt visar

Exchange Online lagrar e-postmeddelanden med deras INTERNALDATE. Outlook Desktop läser detta INTERNALDATE för att visa datumet i kolumnen "Mottaget" och för att sortera inkorgen. Om INTERNALDATE skrevs över under migreringen visar Outlook migreringsdatumet, punkt slut.

Outlook Web App (OWA) gör detsamma. Det finns ingen "alternativ vy" som skulle visa det ursprungliga datumet från Date:-headern. Det du ser i datumkolumnen är INTERNALDATE.

Den ursprungliga Date:-headern finns fortfarande där, intakt, läsbar om du visar ett meddelandets råa headers. Men ingen vanlig vy visar den. Det är kärnfrustrationeringen i det här problemet: rätt information finns, den är bara otillgänglig utan teknisk korrigering.

Det Microsoft-supporten inte löser

Om du öppnar ett ärende hos Microsoft Support för det här problemet får du troligtvis: en bekräftelse på att de visade datumen motsvarar lagrade INTERNALDATE, ett förslag att kontrollera sorteringsinställningarna i Outlook, och eventuellt en hänvisning till det migreringsverktyg du använde.

Det är inte ont uppsåt. Microsoft har helt enkelt inget inbyggt verktyg för att retroaktivt korrigera INTERNALDATE på tusentals meddelanden som redan tagits in i Exchange Online. Korrigeringen kräver att man kommer åt meddelandena individuellt, analyserar deras headers och rekonstruerar datummetadata, vilket ligger utanför standardsupportens räckvidd.

iCloud-supporten å sin sida anser att meddelandena exporterades korrekt och att problemet finns hos destinationen. De två supportsystemen bollar ansvaret mellan sig, och användaren sitter kvar med 12 000 e-postmeddelanden daterade till migreringsdagen.

Skalproblemet

Att förstå varför datumen är trasiga är en sak. Att manuellt korrigera dem i en produktionsbrevlåda är något helt annat.

Vissa IT-administratörer försöker skriptsätta korrigeringen. Grundidén är inte svår att konceptualisera, men att genomföra den på riktiga volymer skapar problem som hemmasnickrade skript inte hanterar väl:

• S/MIME-signerade eller PGP-krypterade e-postmeddelanden kan inte modifieras utan att den kryptografiska signaturen ogiltigförklaras
• Meddelanden med komplexa multipart/alternative-strukturer (HTML + ren text + nästlade bilagor) är sköra att manipulera
• Headers kodade i non-ASCII (RFC 2047, särskilt för japanska, arabiska eller kyrilliska tecken) kan korrupteras av verktyg som inte hanterar dessa kodningar korrekt
• Microsoft Graphs API-kvoter och Exchange Onlines hastighetsgränser (fel 429 Too Many Requests) stoppar skript som inte är byggda för hantering av exponentiell backoff
• Ett skript som fungerar korrekt på 500 testmeddelanden stannar kl. 3 på natten på det 8 000:e meddelandet i en riktig brevlåda, utan återupptagsmekanism

Och frågan som avgör allt: hur verifierar du att varje korrigerat e-postmeddelande är intakt efter korrigeringen? Att bilagan fortfarande finns kvar? Att konversationstråden inte är trasig? Ett hemmasnickrat skript gör i regel inte den verifieringen.

Hur Redate.io hanterar iCloud-migrering till Office 365

Redate.io ansluter direkt till Office 365 via Microsoft 365-behörigheter (Azure AD), utan att behöva åtkomst till iCloud-servrar. E-postmeddelandena finns redan i Exchange Online när Redate träder in.

Redates korrigeringsmotor analyserar headerkedjan i varje meddelande för att identifiera det ursprungliga datumet, och skiljer Received:-headers som lades till under migreringen från legitima datummetadata. Den analysen inkluderar mönstermatchning mot signaturer från hundratals kända migreringsverktyg, vilket gör det möjligt att identifiera parasitiska headers även när de inte är omedelbart uppenbara.

Varje korrigerat e-postmeddelande verifieras individuellt efter behandling. Originalen bevaras i en synlig säkerhetskopieringsmapp i 30 dagar, något inget hemmasnickrat skript gör som standard. Den inledande skanningen är gratis och kvantifierar exakt hur många e-postmeddelanden som påverkats innan du beslutar dig för att korrigera.

Redate.io stöder även migrering från Google Workspace till Office 365 och korrigeringar efter cPanel-migrering. Se till exempel: korrigera e-postdatum efter Microsoft 365-migrering eller felaktiga e-postdatum efter Exchange Online-migrering.

Skanna först, korrigera sedan

Den rekommenderade startpunkten för alla iCloud till Office 365-migreringar som producerat felaktiga datum: kör Redate.ios kostnadsfria skanning på de drabbade brevlådorna. Skanningen identifierar exakt hur många e-postmeddelanden som har ett misstänkt INTERNALDATE och i vilka mappar de finns.

Det tar mellan 12 och 45 minuter beroende på volymen, och ger en tydlig bild av problemets omfattning innan någon åtgärd vidtas. För MSP:er som hanterar flera brevlådor samtidigt efter en migrering, undviker den batchskanningen onödig korrigering av brevlådor som inte behöver det.

Om dina e-postdatum är felaktiga efter en migrering från iCloud, börja med den kostnadsfria skanningen på Redate.io för att mäta problemets omfattning i dina Office 365-brevlådor.