Exchange IMAP-import: derfor aendres e-maildatoer

Exchanges transportpipeline og dine e-maildatoer

Exchange Online har en transportpipeline. Hver besked der kommer ind i en postkasse, uanset om den ankommer fra internettet, flyttes mellem mapper eller importeres via IMAP, passerer gennem denne pipeline. Og pipelinen goer hvad pipelines goer: den stempler beskeden med metadata. Herunder en ny Received:-header med dagens dato.

Det er den egentlige aarsag til datokorruption under Exchange IMAP-imports. Ikke en fejl. Ikke en fejlkonfiguration. En bevidst arkitekturbeslutning fra Microsoft der behandler enhver besked der kommer ind i en postkasse som en "ny levering", selv naar beskeden faktisk er 7 aar gammel.

Resultatet? Du importerer 4.000 e-mails fra en gammel IMAP-server til Exchange Online, og hver eneste viser importdatoen. E-mails fra 2018, 2020, 2023, alle stemplet med dagens dato. Dine brugere aabner Outlook mandag morgen og ser en vaeg af identisk daterede beskeder.

Hvordan EAC-migreringswizarden fungerer

Exchange Admin Center (EAC) indeholder en indbygget migreringswizard til IMAP-imports. Det er den grafiske graenseflade de fleste Exchange-administratorer griber til foerst: man gaar til Modtagere, saa Migrering, opretter en ny batch, vaelger "Migrer til Exchange Online", vaelger IMAP som kilde, uploader en CSV med postkassetilknytninger og starter batchen.

Bag kulisserne opretter EAC-migreringswizarden et New-MigrationBatch med endpointtypen sat til IMAP. Exchange forbinder til din kilde-IMAP-server, laeser hver besked og skriver den ind i maal-Exchange Online-postkassen. Simpelt paa papiret.

Men her er hvad der sker paa transportniveau. Naar Exchange Online modtager beskeden fra IMAP-kilden, behandler det den gennem den samme transportpipeline der haandterer normal e-maillevering. Pipelinen tilfojer en Received:-header med det aktuelle tidsstempel. Den saetter beskedens interne leveringsdato til nu. Og Outlook, OWA og enhver anden klient forbundet til den postkasse bruger denne leveringsdato til visning og sortering.

Den originale Date:-header fra 2019? Stadig der, begravet i beskedhovederne. Men Exchange bruger den ikke til sorteringsraekkefoelgen i din indbakke.

Received: from source-imap.oldserver.com (10.0.0.5) by
    AM6PR04MB5127.eurprd04.prod.outlook.com (2603:10a6:20b:f3::12)
    with Microsoft SMTP Server; Thu, 2 Apr 2026 08:44:19 +0000
Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest og det samme problem

Administratorer der foretraekker kommandolinjen griber ofte til New-MailboxImportRequest til import af PST-filer, eller New-MigrationBatch med IMAP-endpunkter til server-til-server-migreringer. Forventningen er at PowerShell giver mere kontrol. Og det goer det, for visse ting. Ikke for datoer.

New-MailboxImportRequest importerer PST-filer til Exchange Online-postkasser. PST-filen indeholder de originale tidsstempler for hver besked. Men naar Exchange Online behandler importen, stempler transportpipelinen stadig hver besked med en ny leveringsdato. PowerShell-cmdlet'en har ingen parameter til at tilsidesaette denne adfaerd. Der er ingen -PreserveDates-flag (og tro mig, administratorer har ledt efter en).

New-MigrationBatch -SourceEndpoint med et IMAP-endpunkt fungerer paa samme maade som EAC-wizarden, bare uden den grafiske graenseflade. Samme IMAP-forbindelse, samme transportpipelinebehandling, samme datooverskrivning. Cmdlet'en tilbyder parametre til filtrering efter datoraekke (-StartAfter, -CompleteAfter) og ekskludering af mapper, men intet der kontrollerer hvordan Exchange haandterer den indgaaende beskeds tidsstempel.

For at vaere praecis paavirker dette primaert visningsdatoen og sorteringsraekkefoelgen. Beskedindholdet, inklusive den originale Date-header, ankommer intakt. Exchange pakker det simpelthen ind i sine egne transportmetadata og bruger dem til alt synligt for brugeren.

Direkte IMAP-import vs. tredjepartsvaerktojer

Goer det en forskel om du bruger Exchanges native IMAP-import eller et tredjepartsvaerktoej som BitTitan MigrationWiz eller CloudM? Det korte svar: datoproblemet opstaar uanset hvad, men af lidt forskellige aarsager.

Ved Exchanges native IMAP-import (EAC-wizard eller PowerShell) forbinder Exchange selv til kilde-IMAP-serveren og henter beskederne. Transportpipelinen behandler hver besked ved ankomst. En pipeline, et saet tilfoejede headere.

Ved tredjepartsvaerktojer fungerer migreringsvaerktojet som mellemmand. Det laeser fra kilden, transformerer potentielt beskeden og skriver til Exchange Online. Exchanges transportpipeline behandler stadig den indgaaende besked, men tredjepartsvaerktojet kan ogsaa have tilfojet sin egen Received:-header under videreformidlingen. Saa du kan ende med to lag forkerte datometadata: et fra vaerktojets behandling og et fra Exchanges transportpipeline.

Den praktiske forskel? Naar du retter datoer efter en native Exchange IMAP-import, er der typisk en migrerings-Received:-header at haandtere. Efter en tredjepartsvaerktoejimigrering til Exchange kan der vaere to eller tre. Det underliggende problem er identisk, men headerkaeaden er mere rodet.

Hvorfor Exchange Onlines transportregler goer det vaerre

Her er noget der overrasker selv erfarne Exchange-administratorer. Exchange Online har transportregler (nu kaldet "regler for mailflow" i administringscentret) der kan aktiveres paa importerede beskeder. Hvis din organisation har regler der tilfojer headere, ansvarsfraskrivelser eller aendrer beskeder baseret paa betingelser, kan disse regler ogsaa behandle importerede e-mails.

Det betyder at en e-mail fra 2020 ikke blot kan faa en ny Received-header med dagens dato, men ogsaa kan faa en ansvarsfraskrivelse tilfojet, eller en X-header stemplet af en complianceregel der ikke eksisterede da den originale e-mail blev sendt. Datokorruptionen er det mest synlige symptom, men transportregler kan skabe yderligere uventede aeaendringer.

Kan du deaktivere transportregler under import? Ja, midlertidigt. Men de fleste administratorer taenker ikke paa det fordi de ikke forventer at transportpipelinen behandler migrerede beskeder. Naar de indser hvad der er sket, er importbatchen faerdig og skaden sket.

Hvad forkerte datoer betyder i Exchange-miljoeer

Exchange-miljoeer har tendens til at vaere erhvervsmiljoeer. Advokatfirmaer, finansielle institutioner, sundhedsorganisationer, offentlige myndigheder. Det er ikke personlige Gmail-konti hvor en forkert dato er let irriterende. Det er postkasser hvor e-mailtidsstempler har juridisk og regulatorisk betydning.

En retsholdelse i Exchange bevarer e-mails baseret paa datoraekker. Hvis hver importeret e-mail viser importdatoen i stedet for den originale dato, fanger holdelsen det forkerte saet beskeder. En eDiscovery-soegning efter "al kommunikation mellem januar og marts 2022" returnerer intet fordi disse e-mails nu viser april 2026.

Opbevaringspolitikker har det samme problem. En organisation med en 3-aars opbevaringspolitik kunne ved et uheld slette e-mails der synes at vaere fra 2026 (og derfor "nye") naar de faktisk er fra 2019 og burde bevares.

Et scenarie fra slutningen af 2025: en MSP migrerede omkring 200 postkasser fra en hostet Exchange-udbyder til Microsoft 365 ved hjaelp af EAC-migreringswizarden. Tre uger senere flagede kundens complianceofficer at kvartalsrapporter for e-mailarkivering viste hver arkiveret besked med den samme dato. Hele e-mailarkivet, der daekker 5 aar, saa ud til at vaere ankommet paa en enkelt tirsdag i november.

Ret Exchange IMAP-importdatoer

Den originale Date:-header overlever Exchanges transportpipeline intakt. Microsofts pipeline tilfojer metadata omkring beskeden men aendrer ikke de originale RFC 2822-headere indeni. Den originale dato er ankerpunktet for korrektion.

Redate.io forbinder til Exchange Online-postkassen (via Microsoft 365 adminautoriseret adgang), scanner for beskeder med datoanomalier foraarsaget af IMAP-importen og anvender en proprietaer korrektionsmotor der udforer RFC-overensstemmelsesvalidering, beskedstrukturbevarelse og maalrettet metadatarekonstruktion. Motoren genkender Exchange-specifikke transportpipelinesignaturer i Received-headerkaeaden og skelner importartefakter fra legitime leveringsheadere.

Hver korrigeret besked verificeres individuelt: indholdsintegritet, vedhaeftningskontrolsummer, mappeplacering og samtaletraading. Originaler bevares i en synlig backupmappe i 30 dage. Hvis noget ser forkert ud, er tilbagerulning et klik vaek.

Hvorfor ikke rette det med et PowerShell-script? Fordi det at forstaa Received-headerproblemet er den nemme del. At rette 8.000 e-mails i 50 postkasser uden at beskaadige S/MIME-signerede beskeder, brekke indlejrede MIME-strukturer, oedelaegge ikke-ASCII RFC 2047-headere eller miste mappetildelinger, altsa, det er den svaere del. Hvordan verificerer du at hver eneste korrigeret besked i et produktionsmiljoe er intakt? Et script der virker paa en testpostkasse med 30 beskeder gaar ned paa virkelige graensetilfaelde. Den kontrakt med en 42 MB vedhaeftning og tre inline-billeder i en multipart/mixed-struktur inden i en multipart/alternative-wrapper? Held og lykke.

Platformspecifikke vejledninger

Datorettelsen gaelder paa Exchange Online-postkasseniveau, men brugere tilgaar deres e-mail via forskellige klienter. Hver viser datoer forskelligt:

• Ret Exchange IMAP-importdatoer i Outlook
• Ret Exchange IMAP-importdatoer i OWA (Outlook paa nettet)

Leder du efter bredere kontekst om Microsoft 365-datoproblemer med forskellige migreringsvaerktojer? Se den komplette guide til at rette e-maildatoer efter Microsoft 365-migrering.

Exchange IMAP-import efterlod dine postkasser med forkerte datoer? Start med en gratis scanning for at se hvor mange e-mails der er ramt og hvad rettelsen koster, intet kreditkort kraevet.