Exchange IMAP-import: derfor aendres e-maildatoer

Exchange IMAP-import og dine e-maildatoer

Exchange Online giver hver besked i en postkasse en dato, og det er den dato, Outlook viser og sorterer efter. For en e-mail, der kommer fra internettet, er det leveringstidspunktet. For en e-mail, der kopieres ind af en migrering, er det den dato, migreringen gav kopien: den oprindelige, når migreringen sender den videre, importdagen, når den ikke gør det.

Det er her, datofejlene under Exchange IMAP-imports kommer fra. Exchange Online overskriver ikke en dato, den får tildelt. Men når en import ikke bærer hver e-mails oprindelige dato med sig, får kopien af en 7 år gammel besked importens dato, som var den lige blevet leveret.

Resultatet? Du importerer 4.000 e-mails fra en gammel IMAP-server til Exchange Online, og e-mailene viser importdatoen i stedet for deres egen. E-mails fra 2018, 2020, 2023, dateret i dag. Dine brugere åbner Outlook mandag morgen og ser en væg af beskeder med samme dato.

Sådan fungerer migreringswizarden i Exchange Admin Center

Exchange Admin Center (EAC) har en indbygget migreringswizard til IMAP-imports. Det er den grafiske grænseflade, de fleste Exchange-administratorer griber til først: du går til Modtagere, så Migrering, opretter en ny batch, vælger "Migrer til Exchange Online", vælger IMAP som kilde, uploader en CSV med postkassetilknytninger og starter batchen.

Bag kulisserne opretter EAC-migreringswizarden en New-MigrationBatch med endpointtypen sat til IMAP. Exchange forbinder til din kilde-IMAP-server, læser hver besked og skriver den ind i mål-Exchange Online-postkassen. Enkelt nok på papiret.

Men her er hvad administratorer render ind i. Microsoft dokumenterer ikke, hvordan migreringen sætter datoen for hver kopieret besked, og administratorer rapporterer e-mails, der kommer ud med synkroniseringens dato i stedet for den dato, de blev modtaget. Outlook, OWA og alle andre klienter, der er forbundet til den postkasse, bruger derefter denne dato til visning og sortering.

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

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

PowerShell: New-MailboxImportRequest og det samme problem

Administratorer, der foretrækker 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 gør det, for visse ting. Ikke for datoer.

New-MailboxImportRequest importerer PST-filer til Exchange Online-postkasser. PST-filen indeholder de oprindelige tidsstempler for hver besked. Men PowerShell-cmdlet'en har ingen parameter, der styrer, hvilken dato hver importeret besked får. Der er intet -PreserveDates-flag (og tro mig, administratorer har ledt efter et).

New-MigrationBatch -SourceEndpoint med et IMAP-endpunkt fungerer på samme måde som EAC-wizarden, bare uden den grafiske grænseflade. Samme IMAP-forbindelse, samme resultat for datoerne. Cmdlet'en tilbyder parametre til filtrering efter datointerval (-StartAfter, -CompleteAfter) og udelukkelse af mapper, men intet, der styrer, hvordan Exchange håndterer den indgående beskeds tidsstempel.

For at være præcis påvirker dette primært visningsdatoen og sorteringen. Beskedens indhold, inklusive den oprindelige Date-header, ankommer intakt. Kun den dato, kopien fik tildelt, er forkert, og det er den, der ligger bag alt det, brugeren ser.

Direkte IMAP-import kontra tredjepartsværktøjer

Gør det en forskel, om du bruger Exchanges indbyggede IMAP-import eller et tredjepartsværktøj som BitTitan MigrationWiz eller CloudM? Det korte svar: datoproblemet opstår i begge tilfælde, men af lidt forskellige årsager.

Ved Exchanges indbyggede IMAP-import (EAC-wizard eller PowerShell) forbinder Exchange selv til kilde-IMAP-serveren og henter beskederne. Hvordan den sætter datoen for hver kopi, er op til Microsoft og er ikke dokumenteret.

Ved tredjepartsværktøjer fungerer migreringsværktøjet som mellemmand. Det læser fra kilden, transformerer muligvis beskeden og skriver til Exchange Online. Når værktøjet skriver over IMAP, bevarer Exchange Online den dato, værktøjet sender med: hvis værktøjet sender e-mailens oprindelige dato, bevarer kopien den; hvis ikke, får kopien migreringens dato. Nogle værktøjer tilføjer også deres egen Received:-header under videreformidlingen.

Den praktiske forskel? De headere, der efterlades, er ikke de samme fra ét værktøj til et andet, så en rettelse ikke kan bygge på et fast mønster. Det underliggende problem er det samme: den viste dato er ikke e-mailens oprindelige dato.

Hvorfor Exchange Onlines transportregler gør det værre

Her er noget, der overrasker selv erfarne Exchange-administratorer. Exchange Online har transportregler (nu kaldet "regler for mailflow" i administrationscenteret), der kan udløses på importerede beskeder. Hvis din organisation har regler, der tilføjer headere, ansvarsfraskrivelser eller ændrer beskeder baseret på betingelser, kan disse regler også behandle importerede e-mails.

Det betyder, at en e-mail fra 2020 kan få en ansvarsfraskrivelse tilføjet i bunden, eller en X-header stemplet af en complianceregel, der ikke eksisterede, da den oprindelige e-mail blev sendt. De forkerte datoer er det mest synlige symptom, men transportregler kan skabe yderligere uventede ændringer.

Kan du deaktivere transportregler under importen? Ja, midlertidigt. Men de fleste administratorer tænker ikke på det, fordi de ikke forventer, at transportpipelinen overhovedet behandler migrerede beskeder. Når de indser, hvad der er sket, er importbatchen færdig, og skaden er sket.

Hvad forkerte datoer betyder for Exchange-miljøer

Exchange-miljøer er som regel erhvervsmiljøer. Advokatfirmaer, finansielle institutioner, sundhedsorganisationer, offentlige myndigheder. Det er ikke personlige Gmail-konti, hvor en forkert dato er en mild irritation. Det er postkasser, hvor e-mailtidsstempler har juridisk og regulatorisk betydning.

En retsholdelse i Exchange bevarer e-mails baseret på datointervaller. Hvis hver importeret e-mail viser importdatoen i stedet for den oprindelige dato, fanger holdelsen det forkerte sæt beskeder. En eDiscovery-søgning efter "al kommunikation mellem januar og marts 2022" giver ingen resultater, fordi disse e-mails nu viser april 2026.

Opbevaringspolitikker rammer det samme problem. En organisation med en 3-årig opbevaringspolitik kan uforvarende slette e-mails, der ser ud til at være fra 2026 (og derfor "nye"), når de faktisk er fra 2019 og burde bevares. Eller det modsatte: e-mails, der skulle have været slettet under opbevaringspolitikken, bliver liggende, fordi deres tilsyneladende dato er ny.

Et scenarie fra slutningen af 2025: en MSP migrerede omkring 200 postkasser fra en hostet Exchange-udbyder til Microsoft 365 med EAC-migreringswizarden. Tre uger senere flagede kundens complianceansvarlige, at kvartalsrapporterne for e-mailarkivering viste hver arkiveret besked med samme dato. Hele e-mailarkivet, der gik 5 år tilbage, så ud til at være ankommet på en enkelt tirsdag i november.

Ret Exchange IMAP-importdatoer

Den oprindelige Date:-header overlever importen intakt. Importen ændrer ikke de oprindelige RFC 2822-headere i beskeden. Den oprindelige dato er ankerpunktet for rettelsen.

Redate.io forbinder til Exchange Online-postkassen (hver person logger ind med sin egen Microsoft-konto), gennemgår postkassen for beskeder med datoafvigelser forårsaget af IMAP-importen og anvender en egenudviklet rettelsesmotor, der udfører RFC-overensstemmelseskontrol, bevarelse af beskedstrukturen og målrettet genopbygning af metadata. Redate behøver ikke vide, hvilket værktøj der udførte importen: den finder de e-mails, hvis viste dato ikke stemmer med deres oprindelige dato.

Hver rettet besked verificeres individuelt: indholdets integritet, kontrolsummer for vedhæftninger, mappeplacering og samtaletråde. De originale e-mails ligger i en synlig backup-mappe i din egen postkasse, indtil du selv sletter dem. Hvis noget ser forkert ud, er en tilbagerulning et klik væk.

Hvorfor ikke rette det med et PowerShell-script? Fordi det at forstå Received-headerproblemet er den nemme del. At rette 8.000 e-mails i 50 postkasser uden at beskadige S/MIME-signerede beskeder, bryde indlejrede MIME-strukturer, ødelægge non-ASCII RFC 2047-headere eller tabe mappetildelinger, det er den svære del. Hvordan verificerer du, at hver enkelt rettet besked i et produktionsmiljø er intakt, at ingen vedhæftning gik tabt, at ingen samtaletråd blev brudt? Et script, der virker på en testpostkasse med 30 beskeder, vil gå ned på virkelige grænsetilfælde. Den kontrakt med en vedhæftning på 42 MB og tre inline-billeder indlejret i en multipart/mixed-struktur inden i en multipart/alternative-wrapper? Held og lykke.

Platformspecifikke vejledninger

Datorettelsen gælder på Exchange Online-postkasseniveau, men brugerne tilgår deres e-mail via forskellige klienter. Hver klient viser datoer forskelligt:

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

Leder du efter en bredere kontekst om Microsoft 365-datoproblemer på tværs af forskellige migreringsværktøjer? Se den komplette guide til at rette e-maildatoer efter Microsoft 365-migrering.

Efterlod Exchange IMAP-import dine postkasser med forkerte datoer? Start med en gratis gennemgang for at se, hvor mange e-mails der er påvirket, og hvad rettelsen koster, intet kreditkort krævet.