Exchange IMAP-import: derfor endres e-postdatoer

Exchange IMAP-importer og e-postdatoene dine

Exchange Online gir hver melding i en postboks en dato, og det er den datoen Outlook viser og sorterer etter. En e-post som kommer fra internett, får leveringstidspunktet som dato. En e-post som er kopiert inn av en migrering, får derimot den datoen migreringen ga kopien: den opprinnelige når migreringen sender den videre, importdagen når den ikke gjør det.

Det er derfra datokorrupsjon under Exchange IMAP-importer kommer. Exchange Online overskriver ikke en dato den blir gitt. Men når en import ikke bærer med seg hver e-posts opprinnelige dato, får kopien av en 7 år gammel melding importdatoen, som om den nettopp var blitt levert.

Resultatet? Du importerer 4 000 e-poster fra en gammel IMAP-server til Exchange Online, og e-postene viser importdatoen i stedet for sin egen. E-poster fra 2018, 2020, 2023, datert i dag. Brukerne dine åpner Outlook mandag morgen og ser en vegg av identisk daterte meldinger.

Hvordan migreringsveiviseren i Exchange Admin Center fungerer

Exchange Admin Center (EAC) har en innebygd migreringsveiviser for IMAP-importer. Det er det grafiske grensesnittet de fleste Exchange-administratorer griper til først: du går til Mottakere, så 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 endepunkttypen satt til IMAP. Exchange kobler til kilde-IMAP-serveren din, leser hver melding og skriver den inn i mål-postboksen i Exchange Online. Enkelt på papiret.

Men her er det administratorer møter på. Microsoft dokumenterer ikke hvordan migreringen setter datoen på hver kopierte melding, og administratorer melder om e-poster som kommer ut med datoen for synkroniseringen i stedet for datoen de ble mottatt. Outlook, OWA og alle andre klienter koblet til postboksen bruker deretter denne datoen for visning og sortering.

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

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

PowerShell: New-MailboxImportRequest og det samme problemet

Administratorer som foretrekker kommandolinjen, bruker ofte New-MailboxImportRequest til å importere PST-filer, eller New-MigrationBatch med IMAP-endepunkter for server-til-server-migreringer. Forventningen er at PowerShell gir mer kontroll. Og det gjør det, for noen ting. Ikke for datoer.

New-MailboxImportRequest importerer PST-filer til postbokser i Exchange Online. PST-filen inneholder de opprinnelige tidsstemplene for hver melding. Men PowerShell-cmdleten har ingen parameter som styrer hvilken dato hver importerte melding får. Det finnes ingen -PreserveDates-flagg (og tro meg, administratorer har lett etter en).

New-MigrationBatch -SourceEndpoint med et IMAP-endepunkt fungerer på samme måte som EAC-veiviseren, bare uten det grafiske grensesnittet. Samme IMAP-tilkobling, samme resultat for datoer. Cmdleten tilbyr parametere for filtrering etter datoperiode (-StartAfter, -CompleteAfter) og for å utelate mapper, men ingenting som styrer hvordan Exchange behandler tidsstempelet til den innkommende meldingen.

For å være presis, dette påvirker først og fremst visningsdatoen og sorteringen. Meldingsinnholdet, inkludert den opprinnelige Date-headeren, ankommer intakt. Bare datoen kopien fikk er feil, og det er den som ligger bak alt det brukeren ser.

Direkte IMAP-import mot tredjepartsverktøy

Spiller det noen rolle om du bruker Exchanges egen IMAP-import eller et tredjepartsverktøy som BitTitan MigrationWiz eller CloudM? Det korte svaret: datoproblemet oppstår uansett, men av litt forskjellige grunner.

Med Exchanges egen IMAP-import (EAC-veiviseren eller PowerShell) kobler Exchange selv til kilde-IMAP-serveren og henter meldingene. Hvordan den setter datoen på hver kopi, er opp til Microsoft, og det er ikke dokumentert.

Med tredjepartsverktøy fungerer migreringsverktøyet som mellommann. Det leser fra kilden, kan omforme meldingen, og skriver til Exchange Online. Når verktøyet skriver via IMAP, holder Exchange Online seg til datoen verktøyet sender: hvis verktøyet sender hver e-posts opprinnelige dato, holder kopien på den; hvis ikke, får kopien datoen for migreringen. Noen verktøy legger også til sin egen Received:-header under overføringen.

Den praktiske forskjellen? Headerne som blir liggende igjen, er ikke de samme fra ett verktøy til et annet, så en retting kan ikke basere seg på ett fast mønster. Det underliggende problemet er identisk: datoen som vises, er ikke e-postens opprinnelige dato.

Hvorfor Exchange Onlines transportregler gjør det verre

Her er noe som overrasker selv erfarne Exchange-administratorer. Exchange Online har transportregler (nå kalt "regler for meldingsflyt" i administrasjonssenteret) som kan utløses på importerte meldinger. Hvis organisasjonen din har regler som stempler headere, legger til ansvarsfraskrivelser eller endrer meldinger basert på betingelser, kan disse reglene også behandle importerte e-poster.

Det betyr at en e-post fra 2020 kan få en ansvarsfraskrivelse lagt til i bunnen, 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 flere uventede endringer.

Kan du deaktivere transportregler under importen? Ja, midlertidig. Men de fleste administratorer tenker ikke på det, fordi de ikke forventer at transportbehandlingen i utgangspunktet berører migrerte meldinger. Når de innser hva som har skjedd, er importbatchen ferdig, og skaden er skjedd.

Hva feil datoer betyr for Exchange-miljøer

Exchange-miljøer har en tendens til å være forretningsmiljøer. Advokatfirmaer, finansinstitusjoner, helseorganisasjoner, offentlige etater. Disse er ikke personlige Gmail-kontoer der en feil dato er mildt irriterende. Dette er postbokser der e-posttidsstempler har juridisk og regulatorisk betydning.

En rettslig sperring (litigation hold) i Exchange bevarer e-poster basert på datoperioder. Hvis hver importerte e-post viser importdatoen i stedet for den opprinnelige datoen, fanger sperringen feil sett med meldinger. Et eDiscovery-søk etter "all kommunikasjon mellom januar og mars 2022" gir ingen treff, fordi disse e-postene nå viser april 2026.

Oppbevaringspolicyer treffer det samme problemet. En organisasjon med en oppbevaringspolicy på 3 år kan komme til å slette e-poster som ser ut til å være fra 2026 (og derfor "nye"), når de egentlig er fra 2019 og skulle vært bevart. Eller det motsatte: e-poster som skulle vært fjernet under oppbevaringspolicyen, blir liggende fordi den tilsynelatende datoen er ny.

Ett scenario fra slutten av 2025: en MSP migrerte rundt 200 postbokser fra en hostet Exchange-leverandør til Microsoft 365 med EAC-migreringsveiviseren. Tre uker senere flagget kundens compliance-ansvarlige at kvartalsvise arkiveringsrapporter for e-post viste hver arkivert melding med samme dato. Hele e-postarkivet, som gikk 5 år tilbake, så ut til å ha kommet inn på en enkelt tirsdag i november.

Rett Exchange IMAP-importdatoer

Den opprinnelige Date:-headeren overlever importen intakt. Importen endrer ikke de opprinnelige RFC 2822-headerne inne i meldingen. Den opprinnelige datoen er ankerpunktet for rettingen.

Redate.io kobler seg til Exchange Online-postboksen (hver person logger inn med sin egen Microsoft-konto), skanner etter meldinger med datoavvik forårsaket av IMAP-importen, og bruker en egenutviklet korrigeringsmotor som utfører RFC-samsvarsvalidering, bevaring av meldingsstruktur og målrettet metadatarekonstruksjon. Redate trenger ikke å vite hvilket verktøy som utførte importen: det finner e-postene der den viste datoen ikke stemmer med den opprinnelige.

Hver rettet melding blir verifisert individuelt: innholdsintegritet, kontrollsummer for vedlegg, mappeplassering og samtaletråding. Originalene blir liggende i en synlig sikkerhetskopimappe i din egen postboks til du selv sletter dem. Hvis noe ser feil ut, er tilbakerulling ett klikk unna.

Hvorfor ikke rette det med et PowerShell-skript? Fordi det å forstå Received-headerproblemet er den enkle delen. Å rette 8 000 e-poster i 50 postbokser uten å skade S/MIME-signerte meldinger, ødelegge nestede MIME-strukturer, forvrenge ikke-ASCII RFC 2047-headere eller miste mappetilhørighet, det er den vanskelige delen. Hvordan verifiserer du at hver eneste rettede melding i et produksjonsmiljø er intakt, at ingen vedlegg gikk tapt, at ingen samtaletråd ble brutt? Et skript som fungerer på en testpostboks med 30 meldinger, vil kveles av virkelighetens spesialtilfeller. Den kontrakten med et vedlegg på 42 MB og tre integrerte bilder i en multipart/mixed-struktur inne i en multipart/alternative-innpakning? Lykke til.

Plattformspesifikke veiledninger

Datorettingen skjer på postboksnivå i Exchange Online, men brukere får tilgang til e-posten sin gjennom forskjellige klienter. Hver av dem viser datoer på sin egen måte:

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

Leter du etter en bredere sammenheng om Microsoft 365-datoproblemer med forskjellige migreringsverktøy? Se den fulle guiden for å rette e-postdatoer etter migrering til Microsoft 365.

Etterlot Exchange IMAP-importen postboksene dine med feil datoer? Start med en gratis skanning for å se hvor mange e-poster som er berørt og hva rettingen koster, ingen kredittkort nødvendig.