Problemet - alla e-postmeddelanden visar samma datum
Efter en IMAP-migrering öppnar användarna sin brevlåda och möter en oroande syn: varje e-postmeddelande visar exakt samma datum. Istället för det ursprungliga sänd- eller mottagningsdatumet bär alla meddelanden datumet då migreringen genomfördes. Åratal av korrespondens som ser ut att ha anlänt samma dag.
För IT-administratörer är det här en mardröm. Supportärenden strömmar in, användarna hittar ingenting via datumsökning, och brevlådans kronologiska historik är i praktiken förstörd.
Så här ser det ut i Outlook
I Microsoft Outlook visar kolumnen "Mottaget" migreringsdatumet för varje e-postmeddelande. Oavsett om ett meddelande skickades 2018 eller 2023 visar Outlook samma datum, den dag migreringsverktyget behandlade brevlådan. Inkorgen, skickade objekt, varje mapp är drabbad. Användare som förlitar sig på datumsortering får hela sitt arbetsflöde sönderslaget.
Så här ser det ut i Apple Mail
Apple Mail på macOS och iOS beter sig likadant. Datumet som visas bredvid varje meddelande speglar migreringens tidstämpel snarare än det ursprungliga datumet. Eftersom Apple Mail använder IMAP-serverns metadata för att bestämma visningsdatum ger samma underliggande problem samma synliga resultat. Bläddrar du genom inkorgen ser du bara en vägg av identiska datum.
Så här ser det ut i Gmail (webbgränssnittet)
Gmails webbgränssnitt presenterar en lite annorlunda situation. Gmails webbklient använder vanligtvis e-postmeddelandets "Date"-huvud, så meddelanden kan visas med rätt datum i Gmail. Men IMAP INTERNALDATE förblir felaktig, vilket innebär att alla IMAP-klienter som ansluter till det Gmail-kontot (Outlook, Thunderbird, Apple Mail) visar migreringsdatumet. Alltså ser samma brevlåda korrekt ut i en klient men fel i en annan. Ganska förvirrande.
Varför det här händer - den tekniska orsaken
Grundorsaken ligger i hur IMAP-migreringsverktyg hanterar e-posthuvuden och hur e-postklienter bestämmer vilket datum som ska visas. För att förstå detta krävs en kort titt på IMAP-protokollet och huvudstrukturen.
Hur IMAP-migreringsverktyg hanterar huvuden
När ett e-postmeddelande migreras från en server till en annan laddar migreringsverktyget ner det råa meddelandet från källservern och laddar upp det till destinationsservern via IMAP APPEND-kommandot. Under denna process kräver IMAP-protokollet att destinationsservern lägger till ett "Received"-huvud på meddelandet. Detta huvud innehåller en tidstämpel för när meddelandet infogades i den nya servern, det vill säga migreringsdatumet.
"Received"-huvudet som förstör allt
E-postmeddelanden innehåller vanligen flera "Received"-huvuden, vart och ett tillagt av en e-postserver som hanterade meddelandet under den ursprungliga leveransen. Klienter som Outlook bestämmer "mottagningsdatumet" genom att läsa det senaste "Received"-huvudet, det längst upp i kedjan. När ett migreringsverktyg lägger till ett nytt "Received"-huvud med migreringens tidstämpel blir det det senaste, och e-postklienterna visar det datumet istället för det ursprungliga.
Det här är inte en bugg i migreringsverktyget eller e-postklienten. Båda följer IMAP- och e-poststandarderna korrekt. Problemet är att dessa standarder aldrig utformades för massmigrering, och samspelet mellan IMAP APPEND och datumvisningslogiken ger detta oönskade resultat.
INTERNALDATE kontra Date-huvudet
IMAP-servrar lagrar två olika datumvärden för varje meddelande. "Date"-huvudet är en del av själva e-postmeddelandet, det registrerar när meddelandet ursprungligen komponerades och skickades. INTERNALDATE är metadata lagrad av IMAP-servern, som representerar när meddelandet levererades eller infogades på just den servern.
Vissa migreringsverktyg försöker bevara den ursprungliga INTERNALDATE genom att ställa in den under APPEND-kommandot. Men även när INTERNALDATE är korrekt inställd orsakar det tillagda "Received"-huvudet fortfarande problem i klienter som prioriterar "Received"-datumet framför INTERNALDATE.
Vilka migreringsverktyg orsakar problemet?
I princip alla IMAP-migreringsverktyg kan orsaka det här problemet. Frågan är inbyggd i IMAP-protokollet, inte specifik för något enskilt verktyg. Vissa är dock oftare förknippade med problemet på grund av sin utbredda användning.
BitTitan MigrationWiz
BitTitan MigrationWiz är ett av de mest populära kommersiella migreringsverktygen som används av MSP:er och IT-konsulter. MigrationWiz lägger till ett "Received"-huvud som innehåller "mx.migrationwiz.com" under migreringsprocessen. Det huvudet blir det senaste i kedjan, vilket gör att migreringsdatumet visas i Outlook och andra IMAP-klienter. Se detaljerade guider för att korrigera BitTitan-datum i Outlook, Microsoft 365, Google Workspace och Exchange Online.
CloudM Migrate
CloudM Migrate (tidigare Cloud Migrator) används i stor utsträckning för Google Workspace-migreringar. Precis som andra verktyg lägger CloudM till sitt eget "Received"-huvud vid IMAP-infogningen. E-post migrerad med CloudM visar migreringsdatumet i klienter som baseras på "Received"-huvudet. Se guider för att korrigera CloudM-datum i Gmail, Outlook, Google Workspace och Microsoft 365.
imapsync
imapsync är ett populärt verktyg med öppen källkod bland Linux-administratörer och hostingleverantörer. Även om imapsync försöker bevara INTERNALDATE lägger destinationsservern ändå till ett "Received"-huvud under APPEND-operationen. imapsyncs FAQ erkänner denna begränsning men erbjuder ingen inbyggd lösning för att ta bort det tillagda huvudet efter migrering. Se guider för att korrigera imapsync-datum i Outlook, Gmail, Microsoft 365 och Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) är Googles eget verktyg för att migrera från Exchange eller Outlook PST-filer till Google Workspace. GSMMO kan ge samma datumproblem, särskilt när migreringen involverar ett IMAP-mellansteg. Se guider för att korrigera GSMMO-datum i Outlook, Gmail och Apple Mail.
Exchange Admin Center (nativ IMAP-import)
Microsofts Exchange Admin Center innehåller en inbyggd IMAP-importfunktion för migrering till Exchange Online (Microsoft 365). Det här inbyggda migreringsverktyget lägger till "Received"-huvuden under importen, vilket orsakar samma datumvisningsproblem. Se guider för att korrigera Exchange IMAP-migreringsdatum i Outlook och OWA.
Manuell IMAP-kopiering
Även manuell kopiering av e-post mellan IMAP-servrar via en klient som Thunderbird kan ge detta datumproblem. När en e-postklient kopierar ett meddelande via IMAP behandlar destinationsservern det som en ny infogning och lägger till sitt eget "Received"-huvud med aktuell tidstämpel. Se guider för att korrigera manuella IMAP-kopieringsdatum i Outlook, Gmail, Thunderbird och Apple Mail.
Varför vanliga lösningar inte fungerar
Inför det här problemet provar användare och administratörer vanligtvis flera tillvägagångssätt innan de inser att inget av dem faktiskt löser grundproblemet.
"Sortera efter sänddatum" - varför det inte räcker
Det vanligaste förslaget är att byta från sortering på "mottagningsdatum" till "sänddatum" i e-postklienten. Det ändrar visserligen visningsordningen, men det korrigerar inte underliggande data. Sökresultat visar fortfarande fel datum. Kalenderintegrationer, complianceverktyg och automatiserade arbetsflöden som beror på mottagningsdatumet fortsatter att fungera felaktigt. Och användarna måste komma ihåg att ändra inställningen på varje enhet och i varje mapp.
Ny migrering - dyr och riskabel
Vissa administratörer överväger att köra migreringen igen, i hopp om att undvika datumproblemet vid andra försöket. Det tillvägagångssättet är dyrt (500 till 5 000 EUR beroende på antalet brevlådor), tidskrävande och riskabelt. En andra migrering introducerar samma "Received"-huvudproblem, fördubblar risken för dataförlust och kräver betydande driftstopp. Ny migrering löser inte datumproblemet om inte migreringsverktyget ändras i grunden.
Manuell huvudredigering - kräver serveråtkomst
Tekniskt sett innebär korrigeringen att migreringens "Received"-huvud tas bort från varje e-postmeddelande. Men att göra det manuellt kräver direkt serveråtkomst, kunskap om e-posthuvudstrukturer och skräddarsydd skriptning. För en brevlåda med 10 000 e-postmeddelanden är manuell redigering opraktisk och farligt felbemängd. S/MIME-signerade e-postmeddelanden, PGP-krypterade meddelanden, multipart-strukturer med nästlade MIME-gränser, Content-Transfer-Encoding-problem, icke-ASCII-huvuden (RFC 2047), överstora bilagor: vart och ett av dessa fall kan få ett enkelt skript att irreversibelt korruptera data. Hur bekräftar du att 10 000 korrigerade e-postmeddelanden alla är intakta? Det går inte, om man inte har ett verifieringssystem byggt specifikt för det.
Den riktiga lösningen - återställ ursprungliga datum
Rätt tillvägagångssätt är att identifiera migreringsartefakter i varje e-postmeddelandes huvudkedja och tillämpa riktade korrigeringar som återställer den ursprungliga kronologiska ordningen i alla e-postklienter. Det här är inte en enkel huvudredigering. Processen innebär RFC-efterlevnadsvalidering, bevarande av meddelandestruktur och signaturmatchning mot en databas med profiler från kända migreringsverktyg.
Hur Redate.io åtgärdar problemet
Redate.io ansluter till brevlådan (Google Workspace, Microsoft 365 eller vilken IMAP-server som helst) och analyserar varje e-postmeddelande för att identifiera meddelanden som påverkats av migreringshuvuden. Analysen är gratis och visar exakt hur många e-postmeddelanden som berörs innan någon betalning sker.
För varje drabbat e-postmeddelande kör Redate.ios proprietära korrigeringsmotor meddelandet genom en flerstegs analyspipeline. Motorn tillämpar signaturmatchning mot hundratals profiler från kända migreringsverktyg, uppbyggda från behandling av stora volymer verklig e-postdata. Den hanterar kodningsproblem, multipart-strukturer, infogade bilagor och dussintals specialfall som skulle få ett DIY-skript att korruptera data (inte den sortens upptäckt du vill göra en måndagmorgon). Varje korrigerat e-postmeddelande genomgår en integritetskontroll innan det slutförs. Det ursprungliga meddelandet flyttas till en synlig mapp "Redate.io - Originals" (inte raderat) och bevaras i 30 dagar.
Resultatet? E-postmeddelanden visar sina korrekta ursprungliga datum i alla klienter. Sortering fungerar igen. Brevlådans kronologiska historik är återställd.
Vanliga frågor
Kan datum korrigeras månader efter migreringen?
Ja. Det ursprungliga "Date"-huvudet bevaras inuti e-postmeddelandet oavsett när migreringen ägde rum. Redate.io kan korrigera e-postdatum veckor, månader eller till och med år efter migreringen. Korrigeringen fungerar så länge de ursprungliga e-posthuvudena är intakta.
Kommer datumkorrigeringen att radera mina e-postmeddelanden?
Nej. Redate.io raderar aldrig e-postmeddelanden. Ursprungliga meddelanden flyttas till en synlig mapp kallad "Redate.io - Originals" i brevlådan, där de förblir tillgängliga i 30 dagar. Varje korrigerat e-postmeddelande verifieras mot originalet innan processen slutförs. Om verifieringen misslyckas för ett meddelande förblir originalet orört.
Fungerar det med delade brevlådor?
Ja. Redate.io fungerar med delade brevlådor i Google Workspace och Microsoft 365. För delade brevlådor krävs administratörsbehörighet för att auktorisera anslutningen. Processen är identisk med individuella brevlådor: analys, korrigering, verifiering.
Redo att återställa rätt datum? Kör en gratis analys för att se hur många e-postmeddelanden som är drabbade i varje brevlåda.