Exchange IMAP-import: derfor endres e-postdatoer

Exchanges transportpipeline og e-postdatoene dine

Exchange Online har en transportpipeline. Hver melding som kommer inn i en postkasse, enten den ankommer fra internett, flyttes mellom mapper eller importeres via IMAP, passerer gjennom denne pipelinen. Og pipelinen gjoer det pipelines gjoer: den stempler meldingen med metadata. Inkludert en ny Received:-header med dagens dato.

Dette er grunnarsaken til datokorrupsjon under Exchange IMAP-importer. Ikke en feil. Ikke en feilkonfigurasjon. En bevisst arkitekturbeslutning fra Microsoft som behandler hver melding som kommer inn i en postkasse som en "ny levering", selv naar meldingen faktisk er 7 aar gammel.

Resultatet? Du importerer 4 000 e-poster fra en gammel IMAP-server til Exchange Online, og hver eneste viser importdatoen. E-poster fra 2018, 2020, 2023, alle stemplet med dagens dato. Brukerne dine aapner Outlook mandag morgen og ser en vegg av identisk daterte meldinger.

Hvordan EAC-migreringsveiviseren fungerer

Exchange Admin Center (EAC) inkluderer en innebygd migreringsveiviser for IMAP-importer. Det er det grafiske grensesnittet de fleste Exchange-administratorer griper til foerst: man gaar til Mottakere, saa Migrering, oppretter en ny batch, velger "Migrer til Exchange Online", velger IMAP som kilde, laster opp en CSV med postkassekoblinger og starter batchen.

Bak kulissene oppretter EAC-migreringsveiviseren en New-MigrationBatch med endpunkttypen satt til IMAP. Exchange kobler til kilde-IMAP-serveren din, leser hver melding og skriver den inn i maal-Exchange Online-postkassen. Enkelt paa papiret.

Men her er hva som skjer paa transportnivaa. Naar Exchange Online mottar meldingen fra IMAP-kilden, behandler det den gjennom den samme transportpipelinen som haandterer vanlig e-postlevering. Pipelinen legger til en Received:-header med gjeldende tidsstempel. Den setter meldingens interne leveringsdato til naa. Og Outlook, OWA og enhver annen klient koblet til den postkassen bruker denne leveringsdatoen til visning og sortering.

Den opprinnelige Date:-headeren fra 2019? Fortsatt der, begravd i meldingshodene. Men Exchange bruker den ikke til sorteringsrekkefoolgen i innboksen din.

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 problemet

Administratorer som foretrekker kommandolinjen griper ofte til New-MailboxImportRequest for aa importere PST-filer, eller New-MigrationBatch med IMAP-endpunkter for server-til-server-migreringer. Forventningen er at PowerShell gir mer kontroll. Og det gjoer det, for noen ting. Ikke for datoer.

New-MailboxImportRequest importerer PST-filer til Exchange Online-postkasser. PST-filen inneholder de opprinnelige tidsstemplene for hver melding. Men naar Exchange Online behandler importen, stempler transportpipelinen fortsatt hver melding med en ny leveringsdato. PowerShell-cmdleten har ingen parameter for aa overstyre denne oppfoerselen. Det finnes ingen -PreserveDates-flagg (og tro meg, administratorer har lett etter en).

New-MigrationBatch -SourceEndpoint med et IMAP-endpunkt fungerer paa tilsvarende maate som EAC-veiviseren, bare uten det grafiske grensesnittet. Samme IMAP-tilkobling, samme transportpipelinebehandling, samme datooverskrivning. Cmdleten tilbyr parametere for filtrering etter datoperiode (-StartAfter, -CompleteAfter) og for aa ekskludere mapper, men ingenting som styrer hvordan Exchange haandterer tidsstemplet til den innkommende meldingen.

For aa vaere presis paavirker dette hovedsakelig visningsdatoen og sorteringsrekkefoolgen. Meldingsinnholdet, inkludert den opprinnelige Date-headeren, ankommer intakt. Exchange pakker det rett og slett inn i sine egne transportmetadata og bruker disse for alt som er synlig for brukeren.

Direkte IMAP-import vs. tredjepartsverktoy

Spiller det noen rolle om du bruker Exchanges innebygde IMAP-import eller et tredjepartsverktoy som BitTitan MigrationWiz eller CloudM? Det korte svaret: datoproblemet oppstaar uansett, men av litt forskjellige grunner.

Med Exchanges innebygde IMAP-import (EAC-veiviser eller PowerShell) kobler Exchange selv til kilde-IMAP-serveren og henter meldingene. Transportpipelinen behandler hver melding ved ankomst. En pipeline, et sett med tillagte headere.

Med tredjepartsverktoy fungerer migreringsverktoeyet som mellommann. Det leser fra kilden, transformerer potensielt meldingen og skriver til Exchange Online. Exchanges transportpipeline behandler fortsatt den innkommende meldingen, men tredjepartsverktoeyet kan ogsaa ha lagt til sin egen Received:-header under videresendingen. Du kan altsaa ende opp med to lag med feil datometadata: et fra verktoyets behandling og et fra Exchanges transportpipeline.

Den praktiske forskjellen? Naar du fikser datoer etter en innebygd Exchange IMAP-import, er det vanligvis en migrerings-Received:-header aa haandtere. Etter en tredjepartsverktoymigrering til Exchange kan det vaere to eller tre. Det underliggende problemet er identisk, men headerkjeden er mer rotete.

Hvorfor Exchange Onlines transportregler gjoer det verre

Her er noe som overrasker selv erfarne Exchange-administratorer. Exchange Online har transportregler (naa kalt "regler for meldingsflyt" i administrasjonssenteret) som kan utloeses paa importerte meldinger. Hvis organisasjonen din har regler som legger til headere, ansvarsfraskrivelser eller endrer meldinger basert paa betingelser, kan disse reglene behandle importerte e-poster ogsaa.

Det betyr at en e-post fra 2020 ikke bare kan faa en ny Received-header med dagens dato, men ogsaa kan faa en ansvarsfraskrivelse lagt til, eller en X-header stemplet av en compliance-regel som ikke eksisterte da den opprinnelige e-posten ble sendt. Datokorrupsjonen er det mest synlige symptomet, men transportregler kan skape ytterligere uventede endringer.

Kan du deaktivere transportregler under importen? Ja, midlertidig. Men de fleste administratorer tenker ikke paa det fordi de ikke forventer at transportpipelinen behandler migrerte meldinger. Naar de innser hva som har skjedd, er importbatchen ferdig og skaden er skjedd.

Hva feil datoer betyr i Exchange-miljoer

Exchange-miljoer har en tendens til aa vaere forretningsmiljoer. Advokatfirmaer, finansinstitusjoner, helseorganisasjoner, offentlige etater. Dette er ikke personlige Gmail-kontoer der en feil dato er mildt irriterende. Dette er postkasser der e-posttidsstempler har juridisk og regulatorisk betydning.

En rettslig sperring i Exchange bevarer e-poster basert paa datoperioder. Hvis hver importert e-post viser importdatoen i stedet for den opprinnelige datoen, fanger sperringen feil sett med meldinger. Et eDiscovery-soek etter "all kommunikasjon mellom januar og mars 2022" returnerer ingenting fordi disse e-postene naa viser april 2026.

Oppbevaringspolicyer har det samme problemet. En organisasjon med en 3-aars oppbevaringspolicy kunne ved et uhell slette e-poster som tilsynelatende er fra 2026 (og derfor "nye") naar de faktisk er fra 2019 og burde bevares.

Et scenario fra slutten av 2025: en MSP migrerte rundt 200 postkasser fra en hostet Exchange-leverandoer til Microsoft 365 ved hjelp av EAC-migreringsveiviseren. Tre uker senere flagget kundens compliance-ansvarlige at kvartalsrapporter for e-postarkivering viste hver arkivert melding med samme dato. Hele e-postarkivet, som dekket 5 aar, saa ut til aa ha ankommet paa en enkelt tirsdag i november.

Fiks Exchange IMAP-importdatoer

Den opprinnelige Date:-headeren overlever Exchanges transportpipeline intakt. Microsofts pipeline legger til metadata rundt meldingen men endrer ikke de opprinnelige RFC 2822-headerne inni. Den opprinnelige datoen er ankerpunktet for korrigering.

Redate.io kobler til Exchange Online-postkassen (via Microsoft 365 admin-autorisert tilgang), skanner etter meldinger med datoavvik foraarsaket av IMAP-importen og anvender en proprietaer korrigeringsmotor som utfoerer RFC-samsvarvalidering, meldingsstrukturbevaring og maalrettet metadatarekonstruksjon. Motoren gjenkjenner Exchange-spesifikke transportpipelinesignaturer i Received-headerkjeden og skiller importartefakter fra legitime leveringsheadere.

Hver korrigert melding verifiseres individuelt: innholdsintegritet, vedleggskontrollsummer, mappeplassering og samtaletraading. Originaler bevares i en synlig sikkerhetskopimeppe i 30 dager. Hvis noe ser feil ut, er tilbakeruiling et klikk unna.

Hvorfor ikke fikse det med et PowerShell-skript? Fordi det aa forstaa Received-headerproblemet er den enkle delen. Aa rette 8 000 e-poster i 50 postkasser uten aa skade S/MIME-signerte meldinger, brekke nestede MIME-strukturer, oedelegge ikke-ASCII RFC 2047-headere eller miste mappetilordninger, egentlig, det er den vanskelige delen. Hvordan verifiserer du at hver eneste korrigerte melding i et produksjonsmiljoe er intakt? Et skript som virker paa en testpostkasse med 30 meldinger klarer ikke kanttilfellene i den virkelige verden. Den kontrakten med et 42 MB vedlegg og tre inline-bilder i en multipart/mixed-struktur inne i en multipart/alternative-wrapper? Lykke til.

Plattformspesifikke veiledninger

Datokorrigeringen gjelder paa Exchange Online-postkassenivaa, men brukere faar tilgang til e-posten sin via forskjellige klienter. Hver viser datoer forskjellig:

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

Leter du etter bredere kontekst om Microsoft 365-datoproblemer med forskjellige migreringsverktoy? Se den fullstendige guiden for aa rette e-postdatoer etter Microsoft 365-migrering.

Exchange IMAP-import etterlot postkassene dine med feil datoer? Start med en gratis skanning for aa se hvor mange e-poster som er rammet og hva korrigeringen koster, ingen kredittkort noodvendig.