Delad webbhotell till Microsoft 365: dolda datumsfel

Problemet ingen berättade om

Du har precis slutfört migreringen av din e-post från OVH, Infomaniak, Ionos eller o2switch till Microsoft 365. Migreringsguiden i EAC (Exchange Admin Center) körde hela natten, allt lyser grönt, brevlådorna är fyllda. Måndag morgon, första supporten: "Alla mina gamla e-postmeddelanden har dagens datum." Sedan ett till. Sedan tio.

Det är inte ett Microsoft 365-fel. Det är inte heller en slump. Det är det mekaniska resultatet av en IMAP-migrering, och i fallet med ett delat webbhotell är problemet ofta dubbelt så allvarligt som vid en vanlig migrering. Här är varför.

Hur IMAP hanterar datum (och var det går snett)

Varje e-postmeddelande som lagras på en IMAP-server har två olika typer av datering. Å ena sidan finns Date:-headern (definierad i RFC 2822), som ingår i själva meddelandets kropp och anger när meddelandet skickades eller togs emot. Å andra sidan finns INTERNALDATE, en metadata på servernivå som anger när meddelandet lades in i brevlådan. Det är det värdet som e-postklienter som Outlook använder som standard för att sortera och visa e-post.

(Om du någonsin försökt läsa råa e-postheaders i EAC vet du att det inte precis är strandlektyr. Det är lätt tjugo till trettio rader headers innan du ens kommer till innehållet.)

När ett IMAP-migreringsverktyg flyttar ett meddelande från en brevlåda till en annan måste det återskapa INTERNALDATE på destinationen. Vissa verktyg gör det korrekt. Många gör det inte, eller gör det med begränsningar. Mottagarservern, för sin del, behåller det den får: när en kopia bär sitt ursprungliga datum behåller Exchange Online det datumet. Så när datum blir fel är det verktyget man ska granska, inte Microsoft 365.

Resultatet: varje migrerat meddelande verkar ha "tagits emot" den dag migreringen gjordes. Oavsett om det skickades 2019.

Tvåstegskorruptionen: varför delade webbhotell förvärrar allt

Här blir situationen verkligt problematisk för migreringar från delade webbhotell som OVH, Infomaniak, Gandi, Ionos eller o2switch.

De här webbhotellen använder vanligtvis delade Postfix-, Dovecot- eller cPanel-servrar med standard IMAP-konfigurationer. Många SMF-företag har samlat på sig år av e-post där, ibland sedan 2010 eller 2012. När de bestämmer sig för att byta till Microsoft 365 sker migreringen ofta i två steg.

Steg 1: den första korruptionen (innan ens Microsoft 365)

I många fall har e-postmeddelandena redan genomgått en tidigare migrering. Företaget har bytt delat webbhotell en eller två gånger under åren: från Gandi till OVH 2018, sedan från OVH till Infomaniak 2022, till exempel. Varje IMAP-flytt kan ha återställt det ursprungliga INTERNALDATE till flyttdagen (om verktyget inte förde vidare det ursprungliga datumet), och vissa verktyg lämnar dessutom egna migreringsheaders daterade den dagen.

När e-postmeddelandena sedan anländer till Microsoft 365 bär de alltså redan på ärr. Den ursprungliga Date:-headern är intakt (den är en del av meddelandets kropp, ingen rör den), men datummetadatan har redan störts en gång.

Steg 2: den andra korruptionen vid övergången till Exchange Online

EAC:s IMAP-migreringsverktyg, eller ett tredjepartsverktyg som BitTitan MigrationWiz i IMAP-läge, läser sedan in dessa redan skadade meddelanden. Om det verktyget heller inte för vidare varje e-postmeddelandes ursprungliga datum, arkiverar Exchange Online meddelandet under överföringsdagen, och det är det "mottaget datum" Outlook till slut visar.

Ett e-postmeddelande skickat i mars 2017 kan alltså bära två lager av felaktiga datum: migreringsheaders som lämnades kvar av flytten 2022, och ett mottaget datum från migreringen till Microsoft 365 2024. Outlook visar 2024. Användaren ser 2024. Det är fel på två nivåer.

För att vara helt korrekt: det är inte alltid den senaste Received:-headern som används. Outlook bestämmer visningsdatumet utifrån en kombination av INTERNALDATE i Exchange Online-brevlådan och de headers som finns. Men så länge migreringsverktyget inte för vidare de ursprungliga datumen lägger flytten till Exchange Online till ett nytt lager av fel ovanpå det gamla.

Migreringsverktyg och webbhotell: riskfyllda kombinationer

Några kombinationer dyker upp hela tiden i migreringar från delade webbhotell:

• OVH / Infomaniak / Ionos + EAC:s IMAP-verktyg: Microsofts egna verktyg är praktiskt men känt för att inte bevara datum korrekt vid volymmässiga IMAP-migreringar.
• cPanel (o2switch, LWS, m.fl.) + BitTitan MigrationWiz i IMAP-läge: MigrationWiz i IMAP-läge lägger till egna migreringsheaders. Resultatet är dokumenterat, bland annat på sidan åtgärda BitTitan-migreringsdatum i Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync är ett kraftfullt verktyg men hanteringen av INTERNALDATE beror på konfigurationen. Utan rätt alternativ bevaras inte datum. Se även imapsync: datum inte bevarade.
• All manuell migrering via drag-och-släpp i Outlook: om någon kopierat hela mappar genom att dra och släppa mellan två konton i Outlook skrivs INTERNALDATE för varje meddelande om till kopieringsdatumet. Utan undantag.

Den gemensamma nämnaren: alla dessa metoder resulterar i att Exchange Online tar emot e-postmeddelanden vars visade datum i Outlook inte längre stämmer överens med verkligheten.

Varför "fixa det själv" är en dålig idé i stor skala

Att förstå problemet är en sak. Att korrigera 8 000 e-postmeddelanden fördelade i 40 Exchange Online-brevlådor, på konton med komplexa mappstrukturer, S/MIME-signerade meddelanden, stora bilagor och nästlade konversationstrådar, är en helt annan sak.

Ett PowerShell-skript som verkar fungera på tio testmeddelanden kan tyst misslyckas på meddelande nummer 4 237 på grund av en korrumperad MIME-gräns eller en header kodad i RFC 2047 (det formatet =?UTF-8?B?...?= för icke-ASCII-tecken i avsändarnamn). Utan en mekanism för individuell verifiering märker du det inte. Du har bara ett förlorat e-postmeddelande.

Konkreta risker med DIY vid den här typen av migrering:

• Dubbletter om insättningslogiken misslyckas halvvägs
• Saknade bilagor om multipart-strukturen rekonstrueras fel
• Trasiga konversationstrådar i Outlook (trådar baseras på References:- och In-Reply-To:-headers som kan förändras)
• 429-fel (Too Many Requests) från Microsoft Graph API kl. 03:00 på natten, som avbryter bearbetningen utan möjlighet till återställning
• Inget enkelt sätt att verifiera att alla 8 000 korrigeringar faktiskt genomfördes korrekt

Och i det specifika fallet med migreringar från delade webbhotell finns det en extra svårighet: meddelandena bär flera lager av parasitiska Received:-headers, inte bara ett. Ett enkelt skript som tar bort "den senaste Received:" räcker inte. Man måste analysera hela headerkedjan för att identifiera vilken header som hör till vilken migrering, och vilken som faktiskt representerar det ursprungliga mottagningstdatumet.

Vad Redate.io gör annorlunda

Redate.io loggar in med varje användares eget Microsoft-konto, och öppnar bara den e-postlådan med den åtkomst som inloggningen ger. Den inledande skanningen är gratis: Redate.io identifierar alla e-postmeddelanden vars visade datum inte stämmer med det verkliga datumet, och ger en exakt uppskattning per brevlåda.

Korrigeringen bygger på en egenutvecklad korrigeringsmotor som analyserar den fullständiga headerkedjan i varje meddelande, oavsett vilket migreringsverktyg som användes, och rekonstruerar datummetadata korrekt, även när flera korruptionslager lagras ovanpå varandra. Varje korrigerat meddelande verifieras individuellt. Originalen tas aldrig bort: de ligger kvar i en synlig mapp i din egen e-postlåda tills du själv raderar dem.

För migreringar från delade webbhotell hanterar Redate.io:s flerstegsanalys explicit scenarier med dubbel korruption: den nöjer sig inte med att titta på den senaste Received:-headern, utan går igenom hela historiken för att hitta det verkliga mottagningstdatumet. Se även korrigera e-postdatum efter Microsoft 365-migrering för en allmän genomgång, och guiden om IMAP INTERNALDATE som går sönder för att förstå den underliggande mekaniken.

Före eller efter migrering: två tillfällen att agera

Två situationer, två förhållningssätt.

Du har inte migrerat ännu. Det finns goda möjligheter att begränsa skadorna. Vissa migreringsverktyg (MigrationWiz i Exchange-läge, CloudM med rätt inställningar) bevarar datum bättre än andra. Men även i bästa fall kommer en migrering från ett delat webbhotell utan ren historik troligen att lämna spår. Planera in ett pass med Redate.io efter migreringen, innan brevlådorna lämnas till användarna.

Du har redan migrerat och supporten trillar in. Redate.io korrigerar befintliga brevlådor i Microsoft 365, oavsett hur länge sedan migreringen skedde. Skanningen ger dig en exakt bild av det verkliga läget i varje brevlåda innan någon åtgärd vidtas. Se även checklista e-postmigrering för att undvika samma problem i framtiden.

Har du migrerat från OVH, Infomaniak, Ionos eller o2switch till Microsoft 365 och datum är fel? Skapa ett Redate.io-konto för att skanna dina brevlådor gratis och se exakt hur stor skadan är innan du bestämmer dig för något.