Exchange IMAP imports: kāpēc e-pastu datumi kļūdās

Exchange IMAP importi un jūsu e-pastu datumi

Exchange Online piešķir katram pastkastē esošajam ziņojumam datumu, un tas ir datums, ko Outlook rāda un pēc kura kārto. E-pastam, kas ienāk no interneta, tas ir piegādes brīdis. E-pastam, kuru pastkastē ierakstījusi migrācija, tas ir datums, ko migrācija piešķīrusi kopijai: sākotnējais datums, ja migrācija to nodod tālāk, importa diena, ja tā to nedara.

No tā rodas datumu sabojāšana Exchange IMAP importu laikā. Exchange Online nepārraksta datumu, kas tam tiek nodots. Bet, ja imports nenodod katra e-pasta sākotnējo datumu, 7 gadus veca ziņojuma kopija saņem importa datumu, tā, kā tā būtu tikko piegādāta.

Rezultāts? Jūs importējat 4 000 e-pastu no veca IMAP servera Exchange Online, un e-pasti rāda importa datumu, nevis savu. E-pasti no 2018., 2020., 2023. gada, datēti ar šodienu. Jūsu lietotāji pirmdienas rītā atver Outlook un redz sienu no identiski datētiem ziņojumiem.

Kā darbojas Exchange Admin Center migrācijas vednis

Exchange Admin Center (EAC) ietver iebūvētu migrācijas vedni IMAP importiem. Tas ir grafiskais interfeiss, pēc kura vairums Exchange administratoru sniedzas vispirms: jūs dodaties uz Recipients, tad Migration, izveidojat jaunu partiju, izvēlaties "Migrate to Exchange Online", izvēlaties IMAP kā avotu, augšupielādējat CSV failu ar pastkastu kartējumiem un sākat partiju.

Aizkulisēs EAC migrācijas vednis izveido New-MigrationBatch ar galapunkta veidu, kas iestatīts uz IMAP. Exchange pieslēdzas jūsu avota IMAP serverim, nolasa katru ziņojumu un ieraksta to mērķa Exchange Online pastkastē. Uz papīra vienkārši.

Bet ar to administratori saskaras. Microsoft nedokumentē, kā migrācija iestata katras kopētās ziņas datumu, un administratori ziņo par e-pastiem, kas iznāk ar sinhronizācijas datumu, nevis saņemšanas datumu. Outlook, OWA un jebkurš cits klients, kas savienots ar šo pastkasti, tad izmanto šo datumu attēlošanai un kārtošanai.

Sākotnējā Date: galvene no 2019. gada? Joprojām tur, apglabāta ziņojuma galvenēs. Bet Exchange to neizmanto kārtošanas secībai jūsu iesūtnē.

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

PowerShell: New-MailboxImportRequest un tā pati problēma

Administratori, kas dod priekšroku komandrindai, bieži izmanto New-MailboxImportRequest, lai importētu PST failus, vai New-MigrationBatch ar IMAP galapunktiem serveru migrācijām. Gaidas ir, ka PowerShell dod vairāk kontroles. Un tas tā ir, dažām lietām. Ne datumiem.

New-MailboxImportRequest importē PST failus Exchange Online pastkastēs. PST fails satur sākotnējos laika zīmogus katram ziņojumam. Bet PowerShell cmdlet nav parametra, kas kontrolētu, kādu datumu saņem katrs importētais ziņojums. Nav -PreserveDates karodziņa (un ticiet man, administratori to ir meklējuši).

New-MigrationBatch -SourceEndpoint ar IMAP galapunktu darbojas līdzīgi kā EAC vednis, tikai bez grafiskā interfeisa. Tas pats IMAP savienojums, tas pats rezultāts datumiem. Cmdlet piedāvā parametrus filtrēšanai pēc datumu diapazona (-StartAfter, -CompleteAfter) un mapju izslēgšanai, bet nekas, kas kontrolētu, kā Exchange apstrādā ienākošā ziņojuma laika zīmogu.

Precīzāk, tas galvenokārt ietekmē attēloto datumu un kārtošanas secību. Ziņojuma saturs, ieskaitot sākotnējo Date galveni, saglabājas neskarts. Tikai kopijai piešķirtais datums ir nepareizs, un tas ir tas, kas ir aiz visa, ko lietotājs redz.

Tiešais IMAP imports pret trešo pušu rīkiem

Vai ir svarīgi, vai izmantojat Exchange dzimto IMAP importu vai trešās puses rīku, piemēram, BitTitan MigrationWiz vai CloudM? Īsā atbilde: datumu problēma notiek abos gadījumos, taču nedaudz atšķirīgu iemeslu dēļ.

Ar Exchange dzimto IMAP importu (EAC vednis vai PowerShell) Exchange pati pieslēdzas avota IMAP serverim un iegūst ziņojumus. Kā tā iestata katras kopijas datumu, ir Microsoft ziņā, un tas nav dokumentēts.

Ar trešo pušu rīkiem migrācijas rīks darbojas kā starpnieks. Tas nolasa no avota, iespējams, pārveido ziņojumu un ieraksta to Exchange Online. Kad rīks raksta, izmantojot IMAP, Exchange Online patur datumu, ko rīks nodod: ja rīks nosūta katra e-pasta sākotnējo datumu, kopija to patur; ja tas to nedara, kopija saņem migrācijas datumu. Daži rīki turklāt pievieno savu Received: galveni retranslācijas laikā.

Praktiskā atšķirība? Galvenes, kas paliek pāri, nav vienādas no viena rīka uz citu, tāpēc labojums nevar paļauties uz vienu fiksētu shēmu. Pamatproblēma ir identiska: rādītais datums nav e-pasta sākotnējais datums.

Kāpēc Exchange Online pasta plūsmas noteikumi situāciju pasliktina

Šeit ir kaut kas, kas pārsteidz pat pieredzējušus Exchange administratorus. Exchange Online ir transporta noteikumi (administratora centrā tagad sauc "pasta plūsmas noteikumi"), kas var aktivizēties importētiem ziņojumiem. Ja jūsu organizācijai ir noteikumi, kas uzspiež galvenes, pievieno atrunas vai maina ziņojumus atbilstoši nosacījumiem, šie noteikumi var apstrādāt arī importētos e-pastus.

Tas nozīmē, ka e-pastam no 2020. gada var tikt pievienota atrunas kājene vai atbilstības noteikuma uzspiesta X galvene, kas nemaz nepastāvēja, kad sākotnējais e-pasts bija nosūtīts. Datumu sabojāšana ir visredzamākais simptoms, bet transporta noteikumi var radīt papildu neplānotas izmaiņas.

Vai importa laikā var izslēgt transporta noteikumus? Jā, uz laiku. Bet vairums administratoru par to nedomā, jo viņi negaida, ka transporta cauruļvads apstrādās migrētos ziņojumus vispār. Līdz brīdim, kad viņi saprot, kas noticis, importa partija ir pabeigta un kaitējums ir nodarīts.

Ko nepareizi datumi nozīmē Exchange vidēs

Exchange vides mēdz būt biznesa vides. Juridiskās firmas, finanšu iestādes, veselības aprūpes organizācijas, valsts iestādes. Tās nav personiskie Gmail konti, kur nepareizs datums ir vieglprātīgi kaitinošs. Šīs ir pastkastes, kurās e-pasta laika zīmogiem ir juridiska un normatīva nozīme.

Juridiskā aizturēšana Exchange saglabā e-pastus pēc datumu diapazoniem. Ja katrs importētais e-pasts rāda importa datumu, nevis sākotnējo datumu, aizturēšana uztver nepareizo ziņojumu kopu. eDiscovery meklēšana pēc "visas sarakstes starp 2022. gada janvāri un martu" neatgriež nekādus rezultātus, jo šie e-pasti tagad rāda 2026. gada aprīli.

Saglabāšanas politikas saskaras ar tādu pašu problēmu. Organizācija ar 3 gadu saglabāšanas politiku var nejauši izdzēst e-pastus, kas izskatās, ka tie ir no 2026. gada (un tāpēc ir "jauni"), kad tie patiesībā ir no 2019. gada un tiem vajadzētu tikt saglabātiem. Vai pretēji: e-pasti, kuriem vajadzēja tikt izdzēstiem saskaņā ar saglabāšanas politiku, paliek, jo to redzamais datums ir nesens.

Viens scenārijs no 2025. gada beigām: MSP migrēja aptuveni 200 pastkastes no mitināta Exchange nodrošinātāja uz Microsoft 365, izmantojot EAC migrācijas vedni. Trīs nedēļas vēlāk klienta atbilstības speciālists atzīmēja, ka ceturkšņa e-pasta arhivēšanas atskaites rādīja visus arhivētos ziņojumus ar vienu un to pašu datumu. Viss e-pasta arhīvs, kas sniedzās 5 gadus atpakaļ, izskatījās, kā ieradies vienā otrdienā novembrī.

Exchange IMAP importa datumu labošana

Sākotnējā Date: galvene pārdzīvo importu neskarta. Imports nemaina sākotnējās RFC 2822 galvenes ziņojuma iekšpusē. Šis sākotnējais datums ir atsauces punkts labojumam.

Redate.io pieslēdzas Exchange Online pastkastei (katrs cilvēks pierakstās ar savu Microsoft kontu), skenē ziņojumus ar datumu anomālijām, kuras izraisījis IMAP imports, un piemēro paša izstrādātu korekcijas dzinēju, kas veic RFC atbilstības validāciju, ziņojuma struktūras saglabāšanu un mērķtiecīgu metadatu atjaunošanu. Redate nav nepieciešams zināt, kurš rīks veica importu: tas atrod e-pastus, kuru rādītais datums neatbilst to sākotnējam datumam.

Katrs izlabotais ziņojums tiek verificēts individuāli: satura integritāte, pielikumu kontrolsummas, mapes izvietojums un sarakstes pavediens. Sākotnējie ziņojumi paliek redzamā rezerves mapē jūsu pašu pastkastē, līdz jūs pats tos izdzēšat. Ja kaut kas izskatās nepareizi, atgriešanās ir viena klikšķa attālumā.

Kāpēc nelabot to ar PowerShell skriptu? Jo Received galvenes problēmas izpratne ir vieglā daļa. 8 000 e-pastu labošana 50 pastkastēs, nesabojājot S/MIME parakstītus ziņojumus, nesalaužot ligzdotas MIME struktūras, nesagraujot ne-ASCII RFC 2047 galvenes vai nezaudējot mapju piešķīrumus, ir smagā daļa. Kā jūs pārbaudāt, ka katrs izlabotais ziņojums produkcijas vidē ir neskarts, ka neviens pielikums nav pazudis, ka neviens sarakstes pavediens nav pārtrūkis? Skripts, kas darbojas testa pastkastē ar 30 ziņojumiem, aizrīsies uz reālās pasaules robežgadījumiem. Tas līgums ar 42 MB pielikumu un trim iekļautajiem attēliem, iegultiem multipart/mixed struktūrā multipart/alternative apvalkā? Veiksmi.

Platformām specifiskas pamācības

Datumu labojums tiek piemērots Exchange Online pastkastes līmenī, bet lietotāji piekļūst savam e-pastam caur dažādiem klientiem. Katrs no tiem rāda datumus atšķirīgi:

• Labojiet Exchange IMAP importa datumus Outlook
• Labojiet Exchange IMAP importa datumus OWA (Outlook on the Web)

Meklējat plašāku kontekstu par Microsoft 365 datumu problēmām dažādos migrācijas rīkos? Skatiet pilno pamācību e-pastu datumu labošanai pēc Microsoft 365 migrācijas.

Exchange IMAP imports atstāja jūsu pastkastes ar nepareiziem datumiem? Sāciet ar bezmaksas skenēšanu, lai uzzinātu, cik e-pastu ir ietekmēti un cik maksās labošana, bez kredītkartes.