Exchange IMAP-import: waarom e-maildatums veranderen

Exchange IMAP-imports en uw e-maildatums

Exchange Online geeft elk bericht in een mailbox een datum, en dat is de datum die Outlook toont en waarop het sorteert. Voor een e-mail die vanaf internet binnenkomt, is dat het moment van aflevering. Voor een e-mail die door een migratie is gekopieerd, is het de datum die de migratie aan de kopie gaf: de oorspronkelijke datum wanneer de migratie die doorgeeft, de dag van de import wanneer dat niet gebeurt.

Daar komt de datumcorruptie bij Exchange IMAP-imports vandaan. Exchange Online overschrijft geen datum die het krijgt. Maar wanneer een import de oorspronkelijke datum van een e-mail niet meegeeft, krijgt de kopie van een bericht van 7 jaar oud de datum van de import, alsof het net is afgeleverd.

Het resultaat? U importeert 4.000 e-mails van een oude IMAP-server naar Exchange Online, en de e-mails tonen de importdatum in plaats van hun eigen datum. E-mails uit 2018, 2020, 2023, gedateerd op vandaag. Uw gebruikers openen Outlook op maandagochtend en zien een muur van identiek gedateerde berichten.

Hoe de migratiewizard van het Exchange Admin Center werkt

Het Exchange Admin Center (EAC) bevat een ingebouwde migratiewizard voor IMAP-imports. Het is de grafische interface waar de meeste Exchange-beheerders als eerste naar grijpen: u gaat naar Ontvangers, dan Migratie, maakt een nieuwe batch aan, selecteert "Migreren naar Exchange Online", kiest IMAP als bron, uploadt een CSV met mailboxmappings en start de batch.

Achter de schermen maakt de EAC-migratiewizard een New-MigrationBatch met het endpointtype ingesteld op IMAP. Exchange verbindt met uw bron-IMAP-server, leest elk bericht en schrijft het naar de doel-Exchange Online-mailbox. Simpel genoeg op papier.

Maar dit is waar beheerders tegenaan lopen. Microsoft documenteert niet hoe de migratie de datum van elk gekopieerde bericht instelt, en beheerders melden e-mails die met de datum van de synchronisatie tevoorschijn komen in plaats van de datum waarop ze zijn ontvangen. Outlook, OWA en elke andere client die verbonden is met die mailbox gebruikt daarna die datum voor weergave en sortering.

De originele Date:-header uit 2019? Nog steeds aanwezig, begraven in de berichtkoppen. Maar Exchange gebruikt die niet voor de sorteervolgorde in uw postvak.

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

PowerShell: New-MailboxImportRequest en hetzelfde probleem

Beheerders die de voorkeur geven aan de opdrachtregel grijpen vaak naar New-MailboxImportRequest voor het importeren van PST-bestanden, of New-MigrationBatch met IMAP-endpoints voor server-naar-server-migraties. De verwachting is dat PowerShell meer controle biedt. En dat doet het, voor sommige dingen. Niet voor datums.

New-MailboxImportRequest importeert PST-bestanden in Exchange Online-mailboxen. Het PST-bestand bevat de originele tijdstempels voor elk bericht. Maar het PowerShell-cmdlet heeft geen parameter die bepaalt welke datum elk geïmporteerd bericht krijgt. Er is geen -PreserveDates-vlag (en geloof me, beheerders hebben ernaar gezocht).

New-MigrationBatch -SourceEndpoint met een IMAP-endpoint werkt vergelijkbaar met de EAC-wizard, alleen zonder de grafische interface. Dezelfde IMAP-verbinding, hetzelfde resultaat voor datums. Het cmdlet biedt parameters om te filteren op datumbereik (-StartAfter, -CompleteAfter) en mappen uit te sluiten, maar niets dat bepaalt hoe Exchange de tijdstempel van het inkomende bericht behandelt.

Om precies te zijn, dit beïnvloedt vooral de weergavedatum en de sorteervolgorde. De berichtinhoud, inclusief de originele Date-header, komt intact aan. Alleen de datum die de kopie kreeg is verkeerd, en dat is degene die alles bepaalt wat de gebruiker ziet.

Directe IMAP-import versus tools van derden

Maakt het uit of u de native IMAP-import van Exchange gebruikt of een tool van derden zoals BitTitan MigrationWiz of CloudM? Het korte antwoord: het datumprobleem doet zich hoe dan ook voor, maar om iets andere redenen.

Bij de native IMAP-import van Exchange (EAC-wizard of PowerShell) verbindt Exchange zelf met de bron-IMAP-server en haalt berichten op. Hoe het de datum van elke kopie instelt, is aan Microsoft en wordt niet gedocumenteerd.

Bij tools van derden fungeert de migratietool als tussenpersoon. Deze leest van de bron, transformeert mogelijk het bericht en schrijft naar Exchange Online. Wanneer de tool via IMAP schrijft, bewaart Exchange Online de datum die de tool meegeeft: stuurt de tool de oorspronkelijke datum van elke e-mail mee, dan houdt de kopie die; doet de tool dat niet, dan krijgt de kopie de datum van de migratie. Sommige tools voegen tijdens de doorgifte ook hun eigen Received:-header toe.

Het praktische verschil? De headers die achterblijven, verschillen van tool tot tool, dus een herstel kan niet op een vast patroon steunen. Het onderliggende probleem is identiek: de getoonde datum is niet de oorspronkelijke datum van de e-mail.

Waarom de transportregels van Exchange Online het erger maken

Hier is iets dat zelfs ervaren Exchange-beheerders verrast. Exchange Online heeft transportregels (in het beheercentrum nu "regels voor berichtstroom" genoemd) die kunnen worden geactiveerd bij geïmporteerde berichten. Als uw organisatie regels heeft die headers stempelen, disclaimers toevoegen of berichten wijzigen op basis van voorwaarden, kunnen die regels ook geïmporteerde e-mails verwerken.

Dit betekent dat een e-mail uit 2020 een disclaimervoettekst toegevoegd kan krijgen, of een X-header gestempeld door een complianceregel die niet bestond toen de originele e-mail werd verzonden. De datumcorruptie is het meest zichtbare symptoom, maar transportregels kunnen extra onverwachte wijzigingen veroorzaken.

Kunt u transportregels tijdens de import uitschakelen? Ja, tijdelijk. Maar de meeste beheerders denken er niet aan, omdat ze sowieso niet verwachten dat de transportpipeline gemigreerde berichten verwerkt. Tegen de tijd dat ze beseffen wat er is gebeurd, is de importbatch voltooid en is de schade aangericht.

Wat verkeerde datums betekenen voor Exchange-omgevingen

Exchange-omgevingen zijn doorgaans zakelijke omgevingen. Advocatenkantoren, financiële instellingen, zorgorganisaties, overheidsinstanties. Dit zijn geen persoonlijke Gmail-accounts waar een verkeerde datum licht vervelend is. Dit zijn mailboxen waar e-mailtijdstempels juridische en regelgevende betekenis hebben.

Een bewaringsplicht in Exchange bewaart e-mails op basis van datumbereiken. Als elke geïmporteerde e-mail de importdatum toont in plaats van de originele datum, legt de bewaring de verkeerde set berichten vast. Een eDiscovery-zoekopdracht naar "alle communicatie tussen januari en maart 2022" levert niets op, omdat die e-mails nu april 2026 tonen.

Bewaarbeleid heeft hetzelfde probleem. Een organisatie met een bewaarbeleid van 3 jaar zou per ongeluk e-mails kunnen verwijderen die schijnbaar uit 2026 komen (en dus "nieuw" zijn) terwijl ze eigenlijk uit 2019 zijn en bewaard zouden moeten worden. Of het omgekeerde: e-mails die volgens het bewaarbeleid verwijderd hadden moeten worden, blijven bestaan omdat hun schijnbare datum recent is.

Een scenario uit eind 2025: een MSP migreerde ongeveer 200 mailboxen van een gehoste Exchange-provider naar Microsoft 365 met de EAC-migratiewizard. Drie weken later meldde de compliance-functionaris van de klant dat de kwartaalrapporten voor e-mailarchivering elk gearchiveerd bericht met dezelfde datum toonden. Het volledige e-mailarchief, dat 5 jaar besloeg, leek op een enkele dinsdag in november te zijn aangekomen.

Exchange IMAP-importdatums herstellen

De originele Date:-header overleeft de import onbeschadigd. De import wijzigt de originele RFC 2822-headers in het bericht niet. Die originele datum is het ankerpunt voor de correctie.

Redate.io verbindt met de Exchange Online-mailbox (elke persoon meldt zich aan met zijn eigen Microsoft-account), controleert op berichten met datumafwijkingen die door de IMAP-import zijn veroorzaakt, en past een eigen correctie-engine toe die RFC-conformiteitsvalidatie, behoud van berichtstructuur en gerichte metadatareconstructie uitvoert. Redate hoeft niet te weten welke tool de import heeft uitgevoerd: het vindt de e-mails waarvan de getoonde datum niet overeenkomt met hun originele datum.

Elk gecorrigeerd bericht wordt afzonderlijk gecontroleerd: inhoudsintegriteit, bijlagechecksums, mapplaatsing en conversatiethreading. Originelen blijven bewaard in een zichtbare back-upmap van uw eigen mailbox totdat u ze zelf verwijdert. Als iets er niet goed uitziet, is de rollback een klik verwijderd.

Waarom niet herstellen met een PowerShell-script? Omdat het begrijpen van het Received-headerprobleem het makkelijke deel is. 8.000 e-mails in 50 mailboxen corrigeren zonder S/MIME-ondertekende berichten te beschadigen, geneste MIME-structuren te breken, niet-ASCII RFC 2047-headers te verminken of maptoewijzingen te verliezen, dat is het moeilijke deel. Hoe controleert u dat elk gecorrigeerd bericht in een productieomgeving intact is, dat geen bijlage verloren is gegaan, dat geen conversatiethread is gebroken? Een script dat werkt op een testmailbox met 30 berichten, zal falen bij de randgevallen van de echte wereld. Dat contract met een bijlage van 42 MB en drie inline-afbeeldingen ingebed in een multipart/mixed-structuur binnen een multipart/alternative-wrapper? Veel succes.

Platformspecifieke handleidingen

Het herstel van de datum wordt toegepast op het niveau van de Exchange Online-mailbox, maar gebruikers benaderen hun e-mail via verschillende clients. Elk toont datums anders:

• Exchange IMAP-importdatums in Outlook herstellen
• Exchange IMAP-importdatums in OWA herstellen (Outlook op het web)

Op zoek naar bredere context over Microsoft 365-datumproblemen bij verschillende migratietools? Bekijk de volledige gids voor het herstellen van e-maildatums na een Microsoft 365-migratie.

Heeft de Exchange IMAP-import uw mailboxen met verkeerde datums achtergelaten? Begin met een gratis scan om te zien hoeveel e-mails getroffen zijn en wat de correctie kost, geen creditcard nodig.