Exchange IMAP uvoz: zakaj datumi e-pošte grešijo

Exchangeovi uvozi IMAP in datumi vaše e-pošte

Exchange Online vsakemu sporočilu v poštnem predalu dodeli datum, in to je datum, ki ga Outlook prikazuje in po katerem razvršča. Pri e-pošti, ki prispe z interneta, je to trenutek dostave. Pri e-pošti, ki jo prekopira migracija, je to datum, ki ga migracija dodeli kopiji: prvotni datum, kadar ga migracija prenese naprej, dan uvoza, kadar ga ne prenese.

Od tod izvira težava s pokvarjenimi datumi pri uvozih Exchange IMAP. Exchange Online ne prepiše datuma, ki mu je bil dodeljen. Toda kadar uvoz ne prenese prvotnega datuma vsakega sporočila, kopija sporočila, starega 7 let, dobi datum uvoza, kot da bi bila pravkar dostavljena.

Rezultat? Uvozite 4.000 e-poštnih sporočil s starega strežnika IMAP v Exchange Online, in sporočila kažejo datum uvoza namesto svojega. Sporočila iz let 2018, 2020, 2023, datirana na danes. Vaši uporabniki v ponedeljek zjutraj odprejo Outlook in zagledajo zid sporočil z enakim datumom.

Kako deluje čarovnik za migracijo v Exchange Admin Center

Exchange Admin Center (EAC) vključuje vgrajen čarovnik za migracijo za uvoze IMAP. To je grafični vmesnik, po katerem najprej poseže večina skrbnikov Exchange: odprete Prejemniki, nato Migracija, ustvarite novo skupino, izberete "Migriraj v Exchange Online", za vir izberete IMAP, naložite CSV s preslikavami poštnih predalov in zaženete skupino.

V ozadju čarovnik za migracijo ustvari New-MigrationBatch z vrsto končne točke, nastavljeno na IMAP. Exchange se poveže z vašim izvornim strežnikom IMAP, prebere vsako sporočilo in ga zapiše v ciljni poštni predal Exchange Online. Na papirju dovolj preprosto.

Toda na to skrbniki naletijo. Microsoft ne dokumentira, kako migracija določi datum vsakega prekopiranega sporočila, in skrbniki poročajo o sporočilih, ki se izkažejo z datumom sinhronizacije namesto z datumom, ko so bila prejeta. Outlook, OWA in vsak drug odjemalec, povezan s tem poštnim predalom, potem ta datum uporabijo za prikaz in razvrščanje.

Prvotna glava Date: iz leta 2019? Še vedno je tam, skrita med glavami sporočila. Toda Exchange je ne uporabi za vrstni red v vašem nabiralniku.

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

PowerShell: New-MailboxImportRequest in enaka težava

Skrbniki, ki imajo raje ukazno vrstico, se pogosto obrnejo na New-MailboxImportRequest za uvoz datotek PST ali na New-MigrationBatch s končnimi točkami IMAP za migracije med strežniki. Pričakovanje je, da PowerShell omogoča več nadzora. In to za nekatere stvari drži. Ne za datume.

New-MailboxImportRequest uvozi datoteke PST v poštne predale Exchange Online. Datoteka PST vsebuje prvotne časovne žige za vsako sporočilo. Toda ukaz PowerShell nima parametra, ki bi nadzoroval, kateri datum dobi vsako uvoženo sporočilo. Ni zastavice -PreserveDates (in verjemite, skrbniki so jo iskali).

New-MigrationBatch -SourceEndpoint s končno točko IMAP deluje podobno kot čarovnik EAC, le brez grafičnega vmesnika. Enaka povezava IMAP, enak rezultat pri datumih. Ukaz ponuja parametre za filtriranje po datumskem razponu (-StartAfter, -CompleteAfter) in izključevanje map, nič pa, kar bi nadzorovalo, kako Exchange ravna s časovnim žigom prihajajočega sporočila.

Natančneje, to predvsem vpliva na prikazani datum in vrstni red razvrščanja. Vsebina sporočila, vključno s prvotno glavo Date, prispe nepoškodovana. Napačen je samo datum, ki ga dobi kopija, in ta je tisti, ki stoji za vsem, kar uporabnik vidi.

Neposreden uvoz IMAP napram orodjem tretjih oseb

Je pomembno, ali uporabite Exchangeov domači uvoz IMAP ali orodje tretje osebe, kot je BitTitan MigrationWiz ali CloudM? Kratek odgovor: težava z datumi se pojavi v obeh primerih, le zaradi rahlo drugačnih razlogov.

Pri Exchangeovem domačem uvozu IMAP (čarovnik EAC ali PowerShell) se Exchange sam poveže z izvornim strežnikom IMAP in prevzame sporočila. Kako določi datum vsake kopije, je odvisno od Microsofta in ni dokumentirano.

Pri orodjih tretjih oseb orodje za migracijo deluje kot posrednik. Bere iz vira, po potrebi preoblikuje sporočilo in ga zapiše v Exchange Online. Kadar orodje piše prek IMAP, Exchange Online ohrani datum, ki mu ga orodje posreduje: če orodje pošlje prvotni datum vsakega sporočila, ga kopija ohrani; če ga ne pošlje, kopija dobi datum migracije. Nekatera orodja med tem posredovanjem dodajo tudi svojo glavo Received:.

Praktična razlika? Glave, ki ostanejo za orodjem, niso enake od enega orodja do drugega, zato se popravek ne more zanašati na en sam fiksen vzorec. Osnovna težava je enaka: prikazani datum ni prvotni datum e-poštnega sporočila.

Zakaj transportna pravila Exchange Online stvar poslabšajo

Tu je nekaj, kar preseneti tudi izkušene skrbnike Exchange. Exchange Online ima transportna pravila (zdaj v skrbniškem središču imenovana "pravila poštnega toka"), ki se lahko sprožijo na uvoženih sporočilih. Če ima vaša organizacija pravila, ki odtisnejo glave, dodajo izjave o omejitvi odgovornosti ali spremenijo sporočila glede na pogoje, ta pravila lahko obdelajo tudi uvožena sporočila.

To pomeni, da lahko sporočilo iz leta 2020 dobi dodano nogo sporočila z izjavo, ali pa glavo X, ki jo odtisne pravilo o skladnosti, ki ob pošiljanju prvotnega sporočila še ni obstajalo. Pokvarjenje datuma je najbolj opazen simptom, transportna pravila pa lahko povzročijo dodatne nepričakovane spremembe.

Ali lahko transportna pravila med uvozom izklopite? Da, začasno. Toda večina skrbnikov na to ne pomisli, ker sploh ne pričakujejo, da bo transportni cevovod obdelal migrirana sporočila. Ko ugotovijo, kaj se je zgodilo, je skupina za uvoz že zaključena in škoda narejena.

Kaj napačni datumi pomenijo za okolja Exchange

Exchange okolja so navadno poslovna okolja. Odvetniške pisarne, finančne institucije, zdravstvene organizacije, državni organi. To niso osebni računi Gmail, kjer je napačen datum le blago moteč. To so poštni predali, kjer imajo časovni žigi e-pošte pravni in regulativni pomen.

Pravno zadržanje v Exchange ohranja sporočila glede na datumske razpone. Če vsako uvoženo sporočilo kaže datum uvoza namesto prvotnega datuma, zadržanje zajame napačen nabor sporočil. Iskanje eDiscovery za "vso komunikacijo med januarjem in marcem 2022" ne vrne nič, ker ta sporočila zdaj kažejo april 2026.

Politike hrambe naletijo na enako težavo. Organizacija s 3-letno politiko hrambe lahko po nesreči izbriše sporočila, ki se zdijo iz leta 2026 (in so torej "nova"), čeprav so v resnici iz leta 2019 in bi morala biti ohranjena. Ali obratno: sporočila, ki bi morala biti odstranjena po politiki hrambe, ostanejo, ker je njihov navidezni datum nedaven.

En primer iz poznega leta 2025: ponudnik upravljanih storitev je s čarovnikom za migracijo EAC migriral okoli 200 poštnih predalov od gostovanega ponudnika Exchange na Microsoft 365. Tri tedne pozneje je pooblaščenka za skladnost pri stranki opozorila, da četrtletna poročila o arhiviranju e-pošte kažejo vsako arhivirano sporočilo z enakim datumom. Zdelo se je, da je celoten arhiv e-pošte, ki sega 5 let nazaj, prispel na en sam torek novembra.

Popravljanje datumov uvoza Exchange IMAP

Prvotna glava Date: preživi uvoz nepoškodovana. Uvoz ne spremeni prvotnih glav RFC 2822 znotraj sporočila. Ta prvotni datum je oporna točka za popravek.

Redate.io se poveže s poštnim predalom Exchange Online (vsaka oseba se prijavi s svojim Microsoftovim računom), pregleda sporočila z anomalijami datuma, ki jih je povzročil uvoz IMAP, in uporabi lastniški popravni motor, ki izvede preverjanje skladnosti z RFC, ohranitev strukture sporočila in usmerjeno obnovo metapodatkov. Redate ne potrebuje podatka, katero orodje je opravilo uvoz: najde sporočila, katerih prikazani datum se ne ujema z njihovim prvotnim datumom.

Vsako popravljeno sporočilo se preveri posamezno: celovitost vsebine, kontrolne vsote prilog, uvrstitev v mapo in povezanost pogovorov. Izvirniki ostanejo v vidni mapi varnostne kopije v vašem lastnem poštnem predalu, dokler jih ne izbrišete sami. Če je kaj narobe, je povrnitev oddaljena en klik.

Zakaj tega ne popraviti s skriptom v PowerShellu? Ker je razumevanje težave z glavo Received lahek del. Popravljanje 8.000 sporočil v 50 poštnih predalih, ne da bi poškodovali sporočila, podpisana z S/MIME, podrli vgnezdene strukture MIME, popačili glave RFC 2047 z znaki, ki niso ASCII, ali izgubili uvrstitev v mape, je trd del. Kako preverite, da je vsako posamezno popravljeno sporočilo v produkcijskem okolju nepoškodovano, da ni izgubljena nobena priloga, da ni pretrgana nobena veriga pogovora? Skript, ki deluje na testnem poštnem predalu s 30 sporočili, se zaduši ob resničnih robnih primerih. Tista pogodba s prilogo 42 MB in tremi vgrajenimi slikami znotraj strukture multipart/mixed, zavite v ovoj multipart/alternative? Veliko sreče.

Vodniki za posamezne platforme

Popravek datuma se izvede na ravni poštnega predala Exchange Online, uporabniki pa do e-pošte dostopajo prek različnih odjemalcev. Vsak prikazuje datume drugače:

• Popravite datume uvoza Exchange IMAP v Outlooku
• Popravite datume uvoza Exchange IMAP v OWA (Outlook v spletu)

Iščete širši kontekst o vprašanjih datumov Microsoft 365 pri različnih orodjih za migracijo? Oglejte si popoln vodnik za popravljanje datumov e-pošte po migraciji Microsoft 365.

Je uvoz Exchange IMAP pustil vaše poštne predale z napačnimi datumi? Začnite z brezplačnim pregledom, da vidite, koliko sporočil je prizadetih in koliko bo stal popravek, brez potrebne kreditne kartice.