Outlook: IMAP migracijos data vs siuntimo data

Simptomas, kurį visi pažįsta

Ką tik baigėte IMAP migraciją į Microsoft 365 arba Google Workspace. Pirmadienio rytą pradeda plaukti bilietai: „Visi mano laiškai turi tą pačią datą", „Mano istorija sulaužyta", „Nebegaliu nieko rasti savo dėžutėje". Atidarote Outlook ir matote, kad tūkstančiai el. laiškų rodo praėjusio savaitgalio datą. Ne datą, kada jie buvo išsiųsti. Datą, kada vyko migracija.

Tai ne Outlook klaida. Tai tiesioginė IMAP protokolo ir migracijos įrankių veikimo pasekmė. Bet norint suprasti kodėl, reikia atidaryti gaubtelį.

Trys datos viename el. laiške

El. laiškas yra sudėtingesnis, nei atrodo. Antraštė, pranešimo turinys, priedai... ir keli atskiri laiko žymenys, kurie tarpusavyje sugyvena. (Beje, jei kada bandėte skaityti neapdorotą el. laiško antraštę, žinote, kad tai tikrai nėra paplūdimio skaitymas.)

Antraštė Date: (RFC 2822)

Tai data, kurią siuntėjas įrašė į savo pranešimą išsiuntimo metu. Apibrėžta RFC 2822, ji atrodo taip:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Ši antraštė yra įlieta į pranešimo masę. Ji niekada nesikeičia, nebent kas nors pakeičia neapdorotą pranešimo turinį. Tai „siuntimo data" griežtąja prasme.

Antraštė Received: (pridedama kiekviename tinklo šuolyje)

Kiekvienas serveris, per kurį praeina el. laiškas, prideda Received: antraštę pranešimo viršuje su sava data. El. laiškas, praėjęs per tris serverius, surenka tris Received: antraštes. Naujausias visada yra pirmoje vietoje. Tai atrodo maždaug taip:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Rezultatas: kai migracijos įrankis, kaip BitTitan MigrationWiz, CloudM, imapsync ar GSMMO, perkeičia el. laišką iš šaltinio serverio į paskirties serverį, jis pats elgiasi kaip „tinklo šuolis". Jis įterpia naują Received: antraštę krūvos viršuje su migracijos data ir laiku.

IMAP INTERNALDATE

Tai trečioji data, ir būtent ji kelia problemų. INTERNALDATE yra metaduomenys, saugomi IMAP serverio pusėje, nepriklausomai nuo pranešimo turinio. Ji vaizduoja datą, kada el. laiškas buvo pristatytas (arba įterptas) į pašto dėžutę. Kai migracijos įrankis įterpia el. laišką, jis pats pasirenka, kokią reikšmę suteikti INTERNALDATE. Ir daugeliu atvejų įrankiai naudoja migracijos momento datą. Ne originalią datą.

Čia ir viskas užstringa.

Kodėl Outlook rodo migracijos datą

Outlook naudoja INTERNALDATE, kad rodytų stulpelį „Gauta". Tai numatytasis jo elgesys, nuoseklus su IMAP specifikacija: INTERNALDATE turėtų atspindėti gavimo į dėžutę datą. Įprastu srautu (tikras gautas el. laiškas) INTERNALDATE yra artima Date: antraštės datai. Abi yra nuoseklios.

Po nepavykusios migracijos visų importuotų el. laiškų INTERNALDATE rodo 2024 m. birželio 14-15 naktį (arba bet kurią migracijos datą). Outlook nuskaito šią reikšmę, parodo ją stulpelyje „Gauta", ir rezultatas katastrofiškas: 45 000 el. laiškų atrodo, lyg būtų gauti tą patį vakarą.

Tiksliau sakant, pirmoji Received: antraštė (naujausia krūvoje) taip pat turi įtakos rodymui tam tikrose konfigūracijose. Tačiau INTERNALDATE išlieka pagrindinis veiksnys Outlook „Gauta" stulpeliui sinchronizuotu IMAP režimu.

Sprendimas „Pridėti stulpelį Išsiųsta" Outlook programoje

Pirmasis dalykas, kurį daro dauguma IT administratorių aptikę problemą, yra ieškoti sprendimo kliento pusėje. Ir iš tikrųjų toks sprendimas egzistuoja.

Outlook programoje galima modifikuoti aplanko stulpelių rodinį, pakeičiant (arba papildant) stulpelį „Gauta" stulpeliu „Data" arba „Išsiųsta". Stulpelis „Data" tiesiogiai nuskaito pranešimo Date: antraštę, o ne INTERNALDATE. Kadangi Date: antraštės migracija nepaliečia, originalios datos vėl atsiranda.

Kaip tai padaryti Outlook (darbalaukio versija, Microsoft 365): dešiniuoju pelės mygtuku spustelėkite stulpelio antraštę pranešimų sąraše, pasirinkite „Rodinio parametrai", tada pakeiskite stulpelius, pašalindami „Gauta" ir pridėdami „Data". Tai įmanoma per GPO masinio diegimo atveju.

Gerai. Iš pirmo žvilgsnio tai išsprendžia vizualinę problemą. Praktiškai tai pleistras ant arterijos.

Konkretūs šio sprendimo apribojimai

Mobilieji ir žiniatinklio klientai

Outlook iOS, Android ir Outlook Web App (OWA) neturi tų pačių tinkinimo parinkčių. Rodinio pakeitimas, kurį įdiegėte Windows kompiuteriuose, neplatinamas. Jūsų vartotojai, tikrinantys el. paštą telefone, toliau matys migracijos datą. Vidutinio dydžio įmonėje tai greičiausiai pusė visų vartotojų.

Paieška

Outlook paieška naudoja Windows Search indeksą (arba serverio pusėje Exchange/Microsoft 365 indeksą). Šis indeksas kuriamas iš INTERNALDATE, o ne iš Date: antraštės. Jei vartotojas ieško „2022 m. sausio mėn. el. laiškų", paieška grąžina el. laiškus, kurių INTERNALDATE yra 2022 m. sausyje. Ne tuos, kurių Date: antraštė yra 2022 m. sausyje. Rezultatas: seni laiškai nebepasirodo datos filtruose. Stulpelio rodinio keitimas to nepakeičia.

Pašto taisyklės

Outlook taisyklės („jei el. laiškas gautas iki...", „jei el. laiškas gautas po...") taip pat naudoja INTERNALDATE. Rūšiavimo ar archyvavimo taisyklė, pagrįsta datų intervalais, veiks neteisingai po migracijos, jei INTERNALDATE nebuvo pataisyta.

Atitiktis ir eDiscovery

Tai galbūt rimčiausias klausimas. Atitikties, teisinio archyvavimo ir eDiscovery įrankiai (pvz., Microsoft Purview) naudoja INTERNALDATE kaip datos nuorodą teisiniams užklausoms. Jei jūsų įmonei taikomi saugojimo įpareigojimai arba ji turi atsakyti į discovery užklausas, sugadinta INTERNALDATE gali sukelti tikrų teisinių problemų. Auditas, reikalaujantis „visų el. laiškų tarp tokios ir tokios datos", negrąžins teisingų rezultatų.

Trečiųjų šalių įrankiai

CRM, bilietų sistemas, archyvatoriai... viskas, kas jungiasi prie jūsų pašto serverio per IMAP arba Microsoft 365/Google Workspace API, nuskaito INTERNALDATE. Outlook rodinio keitimas nieko nepataiso šioms sistemoms.

Vienintelis tikras sprendimas: taisyti serverio lygmeniu

Rūšiavimas pagal siuntimo datą Outlook programoje nėra sprendimas. Tai pleistras. Tikroji pataisa turi būti atlikta serverio metaduomenų lygmeniu, o ne kliento rodinio lygmeniu.

Konkrečiai tai reiškia kiekvieno el. laiško INTERNALDATE pataisymą, kad ji atitiktų originalią Date: antraštės datą. Originali Date: antraštė visada yra pranešime (migracija jos neištrynė), todėl pataisa yra įmanoma. Čia ir slypi tikroji datos informacija.

Google Workspace aplinkoje Gmail API turi internalDate parametrą, leidžiantį tiesiogiai veikti šiuos metaduomenis. Microsoft 365 atveju mechanizmas skiriasi, tačiau laukiamas rezultatas yra tas pats. Standartiniame IMAP serveryje norma numato, kad data gali būti nurodyta įterpiant pranešimą.

Praktiškai atlikti šią operaciją su dešimtimis tūkstančių el. laiškų gamybinėje aplinkoje, neprarandant duomenų, be dublikatų, nesulaužant diskusijų gijų ar žymų, valdant kraštutines situacijas (S/MIME pasirašyti pranešimai, sudėtingos MIME struktūros, ne ASCII koduotės pagal RFC 2047, dideli priedai)... tai visiškai kitas reikalas. Scenarijus, veikiantis su 50 bandomųjų el. laiškų, neatlaikys 40 000 pranešimų turinčios dėžutės. 429 klaidų (API kvota viršyta) valdymas, tinklo pertraukimai 2 valandą nakties, pranešimai, kurių MIME struktūra jau iš dalies sugadinta po migracijos... visam tam reikia rimtos inžinerijos.

Būtent tai ir daro Redate.io. Nuosavybinis taisymo variklis analizuoja kiekvieno el. laiško antraščių grandinę, identifikuoja patikimą originalią datą ir taiko tikslinę metaduomenų pataisą, neliečiant pranešimo turinio. Kiekvienas pataisytas el. laiškas tikrinamas atskirai. Originalai saugomi atsarginio kopijavimo aplanke 30 dienų, o tai suteikia galimybę bet kada atšaukti pakeitimus. Tai, ko jokia namų gamybos programa niekada nepasiūlys.

Atpažinti atsakingą migracijos įrankį

Problema pasireiškia vienodai, nepriklausomai nuo migracijos kilmės, tačiau detalės skiriasi priklausomai nuo naudoto įrankio. BitTitan MigrationWiz, CloudM, imapsync ir GSMMO kiekvienas turi savo parašą Received: antraštėse, kurias jie įterpia. Redate.io analizės grandinė palaiko atitikmenų bazę, apimančią šimtus žinomų migracijos įrankių parašų, kad galėtų atskirti migracijos antraštę nuo likusios teisėtos tranzito grandinės.

Jei nežinote, koks įrankis buvo naudotas jūsų migracijai (tai pasitaiko, ypač kai perimate aplinką po kito MSP), nemokama Redate.io nuskaitymo funkcija identifikuoja paveiktas dėžutes ir pateikia pataistinų el. laiškų kiekio įvertinimą prieš bet kokius įsipareigojimus.

Specifiniams kontekstams yra išsamių gidų: imapsync datų taisymas Outlook, BitTitan datų taisymas Outlook arba CloudM datų taisymas Outlook.

Ką daryti dabar

Jei skaitote šį straipsnį po migracijos, gera žinia ta, kad originali Date: antraštė yra nepaliesta kiekviename jūsų el. laiške. Tikroji datos informacija yra ten, kiekviename pranešime. Problema yra metaduomenyse, o ne turinyje. O metaduomenis galima pataisyti.

Taip pat galite pažvelgti į straipsnį IMAP INTERNALDATE: kodėl datos sugenda, kad giliau suprastumėte problemos mechaniką, arba išsamų gidą apie klaidingas datas Outlook po migracijos, jei norite apžvalgos visų galimų atvejų.

Pasiruošę pataisyti savo pašto dėžučių datas ? Pradėkite nemokamą nuskaitymą Redate.io, kad identifikuotumėte paveiktus el. laiškus ir įvertintumėte kiekį prieš bet kokią pataisą.