Exchange IMAP importas: kodėl el. laiškų datos klysta

Exchange IMAP importai ir jūsų el. laiškų datos

Exchange Online priskiria kiekvienam pašto dėžutėje esančiam laiškui datą, ir tai yra data, kurią Outlook rodo ir pagal kurią rūšiuoja. El. laiškui, atėjusiam iš interneto, tai yra pristatymo momentas. El. laiškui, nukopijuotam migracijos metu, tai yra data, kurią migracija priskyrė kopijai: pradinė data, kai migracija ją perduoda, arba importo diena, kai ji jos neperduoda.

Iš to kyla neteisingos el. laiškų datos Exchange IMAP importų metu. Exchange Online neperrašo jam suteiktos datos. Bet kai importas neperduoda kiekvieno laiško pradinės datos, prieš 7 metus rašyto pranešimo kopija gauna importo datą, tarsi ji būtų tik dabar pristatyta.

Rezultatas? Importuojate 4 000 el. laiškų iš seno IMAP serverio į Exchange Online, ir el. laiškai rodo importo datą, o ne savo pačių. El. laiškai iš 2018, 2020, 2023 metų, datuoti šiandien. Jūsų vartotojai pirmadienio ryte atsidaro Outlook ir mato sieną iš vienodai datuotų pranešimų.

Kaip veikia Exchange Admin Center migracijos vedlys

Exchange Admin Center (EAC) turi integruotą migracijos vedlį IMAP importams. Tai grafinė sąsaja, prie kurios dauguma Exchange administratorių kreipiasi pirmiausia: eikite į Recipients, tada Migration, sukurkite naują partiją, pasirinkite "Migrate to Exchange Online", kaip šaltinį pasirinkite IMAP, įkelkite CSV su pašto dėžučių susiejimais ir paleiskite partiją.

Užkulisiuose EAC migracijos vedlys sukuria New-MigrationBatch su galinio taško tipu, nustatytu į IMAP. Exchange prisijungia prie jūsų šaltinio IMAP serverio, nuskaito kiekvieną pranešimą ir įrašo jį į tikslinę Exchange Online pašto dėžutę. Popieriuje paprasta.

Bet čia administratoriai susiduria su problema. Microsoft nedokumentuoja, kaip migracija nustato kiekvienos nukopijuotos žinutės datą, ir administratoriai praneša, kad el. laiškai gaunami su sinchronizavimo data, o ne su gavimo data. Outlook, OWA ir kiekvienas kitas klientas, prisijungęs prie tos pašto dėžutės, tada naudoja šią datą rodymui ir rūšiavimui.

Pradinė Date: antraštė iš 2019 metų? Ji tebėra, paslėpta pranešimo antraštėse. Bet Exchange jos nenaudoja rūšiavimo tvarkai jūsų gautuosiuose.

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

PowerShell: New-MailboxImportRequest ir ta pati problema

Administratoriai, kurie renkasi komandinę eilutę, dažnai naudoja New-MailboxImportRequest PST failų importavimui, arba New-MigrationBatch su IMAP galiniais taškais serverio į serverį migracijoms. Tikimasi, kad PowerShell duoda daugiau kontrolės. Ir taip yra, kai kuriems dalykams. Ne datoms.

New-MailboxImportRequest importuoja PST failus į Exchange Online pašto dėžutes. PST faile yra pradiniai kiekvieno pranešimo laiko žymenys. Bet PowerShell cmdlet neturi parametro, kuris valdytų, kokią datą gauna kiekvienas importuotas pranešimas. Nėra -PreserveDates žymos (ir patikėkite, administratoriai jos ieškojo).

New-MigrationBatch -SourceEndpoint su IMAP galiniu tašku veikia panašiai kaip EAC vedlys, tiesiog be grafinės sąsajos. Toks pat IMAP ryšys, toks pat rezultatas datoms. Cmdlet turi parametrus filtravimui pagal datų intervalą (-StartAfter, -CompleteAfter) ir aplankų išskyrimui, bet nieko, kas valdytų, kaip Exchange apdoroja gaunamo pranešimo laiko žymą.

Tiksliau tariant, tai iš esmės veikia rodomą datą ir rūšiavimo tvarką. Pranešimo turinys, įskaitant pradinę Date antraštę, atkeliauja nepakitęs. Tik kopijai priskirta data yra neteisinga, ir tai persmelkia visa, ką vartotojas mato.

Tiesioginis IMAP importas prieš trečių šalių įrankius

Ar svarbu, ar naudojate Exchange natyvų IMAP importą, ar trečios šalies įrankį, tokį kaip BitTitan MigrationWiz ar CloudM? Trumpas atsakymas: datų problema atsiranda bet kuriuo atveju, bet dėl kiek kitokių priežasčių.

Su Exchange natyviu IMAP importu (EAC vedlys arba PowerShell), Exchange pats prisijungia prie šaltinio IMAP serverio ir traukia pranešimus. Kaip jis nustato kiekvienos kopijos datą, priklauso nuo Microsoft, ir tai nedokumentuota.

Su trečių šalių įrankiais migracijos įrankis veikia kaip tarpininkas. Jis nuskaito iš šaltinio, galbūt transformuoja pranešimą, ir įrašo į Exchange Online. Kai įrankis rašo per IMAP, Exchange Online išsaugo datą, kurią įrankis perduoda: jei įrankis siunčia kiekvieno el. laiško pradinę datą, kopija ją išsaugo; jei ne, kopija gauna migracijos datą. Kai kurie įrankiai retransliacijos metu prideda ir savo Received: antraštę.

Praktinis skirtumas? Palikti antraščių pėdsakai nėra vienodi tarp skirtingų įrankių, taigi taisymas negali remtis vienu fiksuotu šablonu. Pagrindinė problema identiška: rodoma data nėra el. laiško pradinė data.

Kodėl Exchange Online pašto srauto taisyklės pablogina situaciją

Tai kažkas, kas nustebina net patyrusius Exchange administratorius. Exchange Online turi transporto taisykles (dabar administravimo centre vadinamas "pašto srauto taisyklėmis"), kurios gali būti aktyvuotos importuotiems pranešimams. Jei jūsų organizacija turi taisykles, kurios uždeda antraštes, prideda atsakomybės apribojimus ar keičia pranešimus pagal sąlygas, tos taisyklės gali apdoroti ir importuotus el. laiškus.

Tai reiškia, kad 2020 metų el. laiškas gali gauti pridėtą atsakomybės apribojimo poraštę arba X antraštę, uždėtą atitikties taisyklės, kuri neegzistavo, kai pradinis el. laiškas buvo išsiųstas. Datos klaida yra labiausiai pastebimas simptomas, bet pašto srauto taisyklės gali sukelti papildomų netikėtų pakeitimų.

Ar galima išjungti pašto srauto taisykles importo metu? Taip, laikinai. Bet dauguma administratorių apie tai nepagalvoja, nes jie nesitiki, kad transporto konvejeris apdoros migruotus pranešimus. Kol jie supranta, kas atsitiko, importo partija jau baigta ir žala padaryta.

Ką neteisingos datos reiškia Exchange aplinkose

Exchange aplinkos paprastai yra verslo aplinkos. Advokatų kontoros, finansų institucijos, sveikatos priežiūros organizacijos, valstybinės įstaigos. Tai ne asmeninės Gmail paskyros, kur neteisinga data yra vos erzinanti. Tai pašto dėžutės, kuriose el. laiškų laiko žymos turi teisinę ir reguliavimo reikšmę.

Teisinis sulaikymas (litigation hold) Exchange sistemoje saugo el. laiškus pagal datų intervalus. Jei kiekvienas importuotas el. laiškas rodo importo datą, o ne pradinę datą, sulaikymas užfiksuoja neteisingą pranešimų rinkinį. eDiscovery paieška "visi pranešimai nuo sausio iki kovo 2022 m." nieko neranda, nes tie el. laiškai dabar rodo 2026 m. balandžio mėnesį.

Duomenų saugojimo politikos (retention policies) susiduria su ta pačia problema. Organizacija su 3 metų saugojimo politika gali netyčia išbraukti el. laiškus, kurie atrodo esą iš 2026 m. (ir todėl "nauji"), kai jie iš tikrųjų yra iš 2019 m. ir turėtų būti saugomi. Arba atvirkščiai: el. laiškai, kurie turėjo būti pašalinti pagal saugojimo politiką, išlieka, nes jų rodoma data yra nesena.

Vienas atvejis iš 2025 m. pabaigos: MSP perkėlė apie 200 pašto dėžučių iš talpinamo Exchange teikėjo į Microsoft 365, naudodamas EAC migracijos vedlį. Po trijų savaičių kliento atitikties pareigūnas pastebėjo, kad ketvirtinės el. laiškų archyvavimo ataskaitos rodė visus archyvuotus pranešimus su ta pačia data. Visas el. pašto archyvas, siekiantis 5 metus atgal, atrodė atkeliavęs vieną antradienį lapkritį.

Exchange IMAP importo datų taisymas

Pradinė Date: antraštė išgyvena importą nepaliesta. Importas nepakeičia pradinių RFC 2822 antraščių pranešimo viduje. Ta pradinė data yra taisymo atskaitos taškas.

Redate.io prisijungia prie Exchange Online pašto dėžutės (kiekvienas žmogus prisijungia su savo Microsoft paskyra), nuskaito pranešimus su datų anomalijomis, kilusiomis dėl IMAP importo, ir taiko Redate sukurtą taisymo variklį, kuris atlieka RFC atitikties patikrą, pranešimo struktūros išsaugojimą ir tikslinę metaduomenų rekonstrukciją. Redate nereikia žinoti, kuris įrankis atliko importą: jis suranda el. laiškus, kurių rodoma data neatitinka jų pradinės datos.

Kiekvienas pataisytas pranešimas patikrinamas individualiai: turinio vientisumas, priedų kontrolinės sumos, aplanko priskyrimas ir pokalbio gijos. Pradiniai laiškai lieka matomame jūsų pačių pašto dėžutės atsarginių kopijų aplanke, kol patys jų neištrinate. Jei kas nors atrodo neteisingai, atšaukimas yra vienu paspaudimu.

Kodėl neišspręsti to PowerShell skriptu? Nes suprasti Received antraštės problemą yra lengvoji dalis. Pataisyti 8 000 el. laiškų 50 pašto dėžutėse, nesugadinant S/MIME pasirašytų pranešimų, nesulaužant įdėtų MIME struktūrų, nesugadinant RFC 2047 koduotų ne-ASCII antraščių ar neprarandant aplankų priskyrimų, yra sunkioji dalis. Kaip patikrinsite, kad kiekvienas pataisytas pranešimas produkcinėje aplinkoje yra vientisas, kad nebuvo praleistas nė vienas priedas, kad nebuvo sulaužyta nė viena pokalbio gija? Skriptas, veikiantis testinėje pašto dėžutėje su 30 pranešimų, užstrigs prie realaus pasaulio kraštutinių atvejų. O ta sutartis su 42 MB priedu ir trimis vidinėmis nuotraukomis, įterptomis į multipart/mixed struktūrą, kuri yra multipart/alternative apvalkale? Sėkmės.

Konkrečių platformų vadovai

Datos taisymas taikomas Exchange Online pašto dėžutės lygmenyje, bet vartotojai pasiekia savo el. laiškus per skirtingus klientus. Kiekvienas juos rodo skirtingai:

• Pataisykite Exchange IMAP importo datas Outlook
• Pataisykite Exchange IMAP importo datas OWA (Outlook on the Web)

Ieškote platesnio konteksto apie Microsoft 365 datų problemas skirtingais migracijos įrankiais? Žiūrėkite pilną vadovą, kaip pataisyti el. laiškų datas po Microsoft 365 migracijos.

Exchange IMAP importas paliko jūsų pašto dėžutes su neteisingomis datomis? Pradėkite nemokamu nuskaitymu, kad sužinotumėte, kiek el. laiškų paveikta ir kiek kainuos pataisymas, kredito kortelė nereikalinga.