Exchange IMAP-import: därför ändras e-postdatum

Exchange IMAP-importer och dina e-postdatum

Exchange Online ger varje e-postmeddelande i en e-postlåda ett datum, och det är detta datum Outlook visar och sorterar efter. För ett e-postmeddelande som kommer in från internet är det leveransögonblicket. För ett e-postmeddelande som kopieras in av en migrering är det vilket datum migreringen gav kopian: det ursprungliga när migreringen skickar det vidare, dagen för importen när den inte gör det.

Det är därifrån datumkorruption vid Exchange IMAP-importer kommer. Exchange Online skriver inte över ett datum det får. Men när en import inte för med sig varje e-postmeddelandes ursprungliga datum får kopian av ett 7 år gammalt meddelande importens datum, som om det just hade levererats.

Resultatet? Du importerar 4 000 e-postmeddelanden från en gammal IMAP-server till Exchange Online, och e-postmeddelanden visar importdatumet istället för sitt eget. E-post från 2018, 2020, 2023, daterad idag. Dina användare öppnar Outlook på måndagsmorgonen och ser en vägg av identiskt daterade meddelanden.

Hur migreringsguiden i Exchange Admin Center fungerar

Exchange Admin Center (EAC) innehåller en inbyggd migreringsguide för IMAP-importer. Det är det grafiska gränssnittet som de flesta Exchange-administratörer tar till först: du går till Mottagare, sedan Migrering, skapar en ny batch, väljer "Migrera till Exchange Online", väljer IMAP som källa, laddar upp en CSV med e-postlådemappningar och startar batchen.

Bakom kulisserna skapar EAC-migreringsguiden en New-MigrationBatch med endpointtypen inställd på IMAP. Exchange ansluter till din käll-IMAP-server, läser varje meddelande och skriver det till mål-e-postlådan i Exchange Online. Enkelt på pappret.

Men det är här administratörer stöter på problem. Microsoft dokumenterar inte hur migreringen sätter datumet för varje kopierat meddelande, och administratörer rapporterar e-postmeddelanden som kommer ut med synkroniseringens datum istället för det datum de mottogs. Outlook, OWA och alla andra klienter anslutna till den e-postlådan använder sedan det datumet för visning och sortering.

Den ursprungliga Date:-headern från 2019? Fortfarande där, begravd i meddelandeheadrarna. Men Exchange använder den inte för sorteringsordningen i din inkorg.

Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest och samma problem

Administratörer som föredrar kommandoraden vänder sig ofta till New-MailboxImportRequest för att importera PST-filer, eller New-MigrationBatch med IMAP-endpoints för server-till-server-migreringar. Förväntningen är att PowerShell ger mer kontroll. Och det gör det, för vissa saker. Inte för datum.

New-MailboxImportRequest importerar PST-filer till e-postlådor i Exchange Online. PST-filen innehåller de ursprungliga tidsstämplarna för varje meddelande. Men PowerShell-cmdleten har ingen parameter som styr vilket datum varje importerat meddelande får. Det finns ingen -PreserveDates-flagga (och tro mig, administratörer har sökt efter en).

New-MigrationBatch -SourceEndpoint med en IMAP-endpoint fungerar på liknande sätt som EAC-guiden, bara utan det grafiska gränssnittet. Samma IMAP-anslutning, samma resultat för datum. Cmdleten erbjuder parametrar för filtrering efter datumintervall (-StartAfter, -CompleteAfter) och för att utesluta mappar, men inget som styr hur Exchange hanterar det inkommande meddelandets tidsstämpel.

För att vara exakt påverkar detta främst visningsdatumet och sorteringsordningen. Meddelandeinnehållet, inklusive den ursprungliga Date-headern, anländer intakt. Bara datumet kopian fick är fel, och det är det som ligger bakom allt som är synligt för användaren.

Direkt IMAP-import jämfört med tredjepartsverktyg

Spelar det någon roll om du använder Exchanges inbyggda IMAP-import eller ett tredjepartsverktyg som BitTitan MigrationWiz eller CloudM? Det korta svaret: datumproblemet uppstår i båda fallen, men av lite olika orsaker.

Med Exchanges inbyggda IMAP-import (EAC-guiden eller PowerShell) ansluter Exchange själv till käll-IMAP-servern och hämtar meddelandena. Hur den sätter datumet för varje kopia är upp till Microsoft, och det är inte dokumenterat.

Med tredjepartsverktyg agerar migreringsverktyget som mellanhand. Det läser från källan, kan omvandla meddelandet, och skriver till Exchange Online. När verktyget skriver via IMAP behåller Exchange Online det datum verktyget skickar: om verktyget skickar varje e-postmeddelandes ursprungliga datum behåller kopian det, om det inte gör det får kopian migreringens datum. Vissa verktyg lägger dessutom till sin egen Received:-header under reläet.

Den praktiska skillnaden? Headrarna som lämnas kvar är inte de samma från ett verktyg till ett annat, så en fix inte kan förlita sig på ett enda fast mönster. Det underliggande problemet är identiskt: datumet som visas är inte e-postmeddelandets ursprungliga datum.

Varför Exchange Onlines transportregler gör det värre

Här är något som överraskar även erfarna Exchange-administratörer. Exchange Online har transportregler (numera kallade "regler för e-postflöde" i administrationscentret) som kan utlösas på importerade meddelanden. Om din organisation har regler som stämplar headrar, lägger till ansvarsfriskrivningar eller ändrar meddelanden baserat på villkor kan dessa regler bearbeta importerade e-postmeddelanden också.

Det innebär att ett e-postmeddelande från 2020 kan få en ansvarsfriskrivning tillagd i sidfoten, eller en X-header stämplad av en efterlevnadsregel som inte existerade när det ursprungliga e-postmeddelandet skickades. Datumkorruptionen är det mest synliga symptomet, men transportregler kan skapa ytterligare oväntade ändringar.

Kan du inaktivera transportregler under importen? Ja, tillfälligt. Men de flesta administratörer tänker inte på det eftersom de inte förväntar sig att transportpipelinen bearbetar migrerade meddelanden över huvud taget. När de inser vad som har hänt är importbatchen klar och skadan skedd.

Vad felaktiga datum innebär för Exchange-miljöer

Exchange-miljöer tenderar att vara företagsmiljöer. Advokatbyråer, finansinstitut, vårdorganisationer, myndigheter. Det här är inte personliga Gmail-konton där ett felaktigt datum är lindrigt irriterande. Det här är e-postlådor där e-posttidsstämplar har juridisk och regulatorisk betydelse.

En rättslig spärr i Exchange bevarar e-post baserat på datumintervall. Om varje importerat e-postmeddelande visar importdatumet istället för det ursprungliga datumet fångar spärren fel uppsättning meddelanden. En eDiscovery-sökning efter "all kommunikation mellan januari och mars 2022" returnerar ingenting eftersom dessa e-postmeddelanden nu visar april 2026.

Bevarandepolicyer drabbas av samma problem. En organisation med en treårig bevarandepolicy kan oavsiktligt radera e-postmeddelanden som verkar vara från 2026 (och därför "nya") när de faktiskt är från 2019 och borde bevaras. Eller tvärtom: e-postmeddelanden som borde ha rensats bort enligt bevarandepolicyn finns kvar eftersom deras skenbara datum är nytt.

Ett scenario från slutet av 2025: en MSP migrerade omkring 200 e-postlådor från en hostad Exchange-leverantör till Microsoft 365 med EAC-migreringsguiden. Tre veckor senare flaggade kundens compliance-ansvarige att kvartalsrapporter för e-postarkivering visade varje arkiverat meddelande med samma datum. Hela e-postarkivet, som sträckte sig 5 år tillbaka, verkade ha anlänt en enda tisdag i november.

Fixa Exchange IMAP-importdatum

Den ursprungliga Date:-headern överlever importen intakt. Importen ändrar inte de ursprungliga RFC 2822-headrarna inuti meddelandet. Det är det ursprungliga datumet som Redate fixar utifrån.

Redate.io ansluter till e-postlådan i Exchange Online (var och en loggar in med sitt eget Microsoft-konto), genomsöker efter meddelanden med datumavvikelser orsakade av IMAP-importen, och tillämpar en egenutvecklad motor som fixar dem genom RFC-överensstämmelsevalidering, bevarande av meddelandestruktur och riktad metadatarekonstruktion. Redate behöver inte veta vilket verktyg som gjorde importen: det hittar e-postmeddelandena vars visade datum inte matchar deras ursprungliga datum.

Varje fixat meddelande verifieras individuellt: innehållsintegritet, kontrollsummor för bilagor, mappplacering och konversationstrådning. Originalen ligger kvar i en synlig säkerhetskopiemapp i din egen e-postlåda tills du själv tar bort dem. Om något ser fel ut är återställning ett klick bort.

Varför inte fixa det med ett PowerShell-skript? För att förstå Received-headerproblemet är den lätta delen. Att fixa 8 000 e-postmeddelanden i 50 e-postlådor utan att skada S/MIME-signerade meddelanden, bryta nästlade MIME-strukturer, förstöra icke-ASCII RFC 2047-headrar eller förlora mapptillhörigheter är den svåra delen. Hur verifierar du att varje enskilt fixat meddelande i en produktionsmiljö är intakt, att ingen bilaga gick förlorad, att ingen konversationstråd bröts? Ett skript som fungerar på en testlåda med 30 meddelanden ger upp inför verklighetens kantfall. Det kontraktet med en 42 MB stor bilaga och tre inbäddade bilder i en multipart/mixed-struktur inuti en multipart/alternative-wrapper? Lycka till.

Plattformsspecifika guider

Datumfixet tillämpas på e-postlådenivå i Exchange Online, men användare kommer åt sin e-post via olika klienter. Var och en visar datum olika:

• Åtgärda Exchange IMAP-importdatum i Outlook
• Åtgärda Exchange IMAP-importdatum i OWA (Outlook på webben)

Letar du efter ett bredare perspektiv på Microsoft 365-datumproblem med olika migreringsverktyg? Se den fullständiga guiden för att fixa e-postdatum efter Microsoft 365-migrering.

Lämnade Exchange IMAP-importen dina e-postlådor med felaktiga datum? Börja med en gratis genomsökning för att se hur många e-postmeddelanden som påverkas och vad det kostar att fixa dem, inget kreditkort krävs.