Problema - visi el. laiškai rodo tą pačią datą
Po IMAP migracijos naudotojai atidaro savo pašto dėžutę ir pamato nerimą keliantį vaizdą: kiekvienas el. laiškas rodo lygiai tą pačią datą. Vietoj originalios išsiuntimo ar gavimo datos visi pranešimai žymimi data, kada buvo atlikta migracija. Metų korespondencija atrodo tarsi būtų atėjusi tą pačią dieną.
IT administratoriams tai tikras košmaras. Užklausos plūsta, naudotojai nebegali nieko rasti pagal datą, o pašto dėžutės chronologinė istorija iš tikrųjų yra sunaikinta.
Kaip tai atrodo „Outlook" programoje
„Microsoft Outlook" stulpelyje „Gauta" rodoma migracijos data kiekvienam el. laiškui. Nesvarbu, ar pranešimas buvo išsiųstas 2018, ar 2023 metais - „Outlook" rodo tą pačią datą, t. y. dieną, kai migracijos įrankis apdorojo pašto dėžutę. Paveikti visi aplankai: gautieji, išsiųstieji ir kiti. Naudotojai, kurie remiasi rūšiavimu pagal datą, praranda darbo eigą.
Kaip tai atrodo „Apple Mail" programoje
„Apple Mail" „macOS" ir „iOS" sistemose elgiasi panašiai. Šalia kiekvieno pranešimo rodoma data atspindi migracijos laiko žymą, o ne originalią datą. Kadangi „Apple Mail" naudoja IMAP serverio metaduomenis datoms nustatyti, ta pati pagrindinė problema sukelia tą patį matomą rezultatą. Naršant gautuosius, matoma tik vienodų datų siena.
Kaip tai atrodo „Gmail" žiniatinklio sąsajoje
„Gmail" žiniatinklio sąsajoje situacija šiek tiek skiriasi. „Gmail" žiniatinklio klientas paprastai naudoja paties el. laiško antraštę „Date", todėl pranešimai gali būti rodomi su teisinga data. Tačiau IMAP INTERNALDATE lieka klaidinga, o tai reiškia, kad bet kuris IMAP klientas, prisijungiantis prie šios „Gmail" paskyros („Outlook", „Thunderbird", „Apple Mail"), rodys migracijos datą. Taigi ta pati pašto dėžutė viename kliente atrodo teisingai, o kitame - klaidingai.
Kodėl taip nutinka - techninė priežastis
Pagrindinė priežastis slypi tame, kaip IMAP migracijos įrankiai tvarko el. pašto antraštes ir kaip el. pašto klientai nustato, kurią datą rodyti. Norint tai suprasti, reikia trumpai pažvelgti į IMAP protokolą ir antraščių struktūrą.
Kaip IMAP migracijos įrankiai tvarko antraštes
Kai el. laiškas migruojamas iš vieno serverio į kitą, migracijos įrankis atsisiunčia neapdorotą pranešimą iš šaltinio serverio ir įkelia jį į paskirties serverį per IMAP APPEND komandą. Šio proceso metu IMAP protokolas reikalauja, kad paskirties serveris pridėtų „Received" antraštę prie pranešimo. Ši antraštė turi laiko žymą, kada pranešimas buvo įterptas į naują serverį, t. y. migracijos datą.
„Received" antraštė, kuri viską sugadina
El. pašto pranešimuose paprastai yra kelios „Received" antraštės, kiekvieną prideda el. pašto serveris, tvarkęs pranešimą jo originalaus pristatymo metu. Tokie klientai kaip „Outlook" nustato „gavimo datą" skaitydami naujausią „Received" antraštę - tą, kuri yra grandinės viršuje. Kai migracijos įrankis prideda naują „Received" antraštę su migracijos laiko žyma, ji tampa naujausia, ir el. pašto klientai rodo šią datą vietoj originalios.
Tai nėra nei migracijos įrankio, nei el. pašto kliento klaida. Abu teisingai laikosi IMAP ir el. pašto standartų. Problema kyla dėl to, kad šie standartai niekada nebuvo sukurti masinei migracijai, o IMAP APPEND ir datų rodymo logikos sąveika sukuria šį nepageidaujamą rezultatą.
INTERNALDATE ir antraštė „Date"
IMAP serveriai saugo dvi skirtingas datų reikšmes kiekvienam pranešimui. Antraštė „Date" yra paties el. laiško dalis - ji fiksuoja, kada pranešimas buvo sukurtas ir išsiųstas. INTERNALDATE yra IMAP serverio saugomi metaduomenys, rodantys, kada pranešimas buvo pristatytas ar įterptas į tą konkretų serverį.
Kai kurie migracijos įrankiai bando išsaugoti originalią INTERNALDATE reikšmę, nustatydami ją per APPEND komandą. Tačiau net kai INTERNALDATE nustatyta teisingai, pridėta „Received" antraštė vis tiek sukelia problemų klientuose, kurie teikia pirmenybę „Received" datai, o ne INTERNALDATE.
Kokie migracijos įrankiai sukelia šią problemą?
Praktiškai visi IMAP migracijos įrankiai gali sukelti šią problemą. Problema būdinga IMAP protokolui, o ne konkrečiam įrankiui. Tačiau kai kurie dažniau siejami su šia problema dėl plačiai paplitusio naudojimo.
BitTitan MigrationWiz
BitTitan MigrationWiz yra vienas populiariausių komercinių migracijos įrankių, naudojamų MSP ir IT konsultantų. MigrationWiz migracijos proceso metu prideda „Received" antraštę su nuoroda „mx.migrationwiz.com". Ši antraštė tampa naujausia grandinėje, todėl migracijos data rodoma „Outlook" ir kituose IMAP klientuose. Žr. išsamius vadovus: BitTitan datų taisymas „Outlook", Microsoft 365, Google Workspace ir Exchange Online.
CloudM Migrate
CloudM Migrate (anksčiau Cloud Migrator) plačiai naudojamas „Google Workspace" migracijoms. Kaip ir kiti įrankiai, CloudM prideda savo „Received" antraštę IMAP įterpimo metu. El. laiškai, migruoti naudojant CloudM, rodo migracijos datą klientuose, kurie remiasi „Received" antrašte. Žr. vadovus: CloudM datų taisymas „Gmail", Outlook, Google Workspace ir Microsoft 365.
imapsync
imapsync yra populiarus atvirojo kodo įrankis tarp „Linux" administratorių ir prieglobos paslaugų teikėjų. Nors imapsync bando išsaugoti INTERNALDATE, paskirties serveris vis tiek prideda „Received" antraštę per APPEND operaciją. imapsync DUK pripažįsta šį apribojimą, tačiau nesiūlo integruoto sprendimo po migracijos pridėtai antraštei pašalinti. Žr. vadovus: imapsync datų taisymas „Outlook", Gmail, Microsoft 365 ir Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) yra „Google" įrankis migracijai iš „Exchange" ar „Outlook" PST failų į „Google Workspace". GSMMO gali sukelti tą pačią datų problemą, ypač kai migracija apima tarpinį IMAP etapą. Žr. vadovus: GSMMO datų taisymas „Outlook", Gmail ir Apple Mail.
Exchange administravimo centras (vietinis IMAP importas)
„Microsoft" „Exchange" administravimo centras turi vietinę IMAP importo funkciją migracijai į „Exchange Online" („Microsoft 365"). Šis integruotas migracijos įrankis prideda „Received" antraštes importo metu, sukeldamas tą pačią datų rodymo problemą. Žr. vadovus: Exchange IMAP migracijos datų taisymas „Outlook" ir OWA.
Rankinis IMAP kopijavimas
Net rankinis el. laiškų kopijavimas tarp IMAP serverių per tokį klientą kaip „Thunderbird" gali sukelti šią datų problemą. Kai el. pašto klientas kopijuoja pranešimą per IMAP, paskirties serveris traktuoja tai kaip naują įterpimą ir prideda savo „Received" antraštę su esama laiko žyma. Žr. vadovus: rankinio IMAP kopijavimo datų taisymas „Outlook", Gmail, Thunderbird ir Apple Mail.
Kodėl įprasti apėjimai neveikia
Susidūrę su šia problema, naudotojai ir administratoriai paprastai išbando kelis būdus, kol supranta, kad nė vienas iš jų tikrai neišsprendžia problemos.
„Rūšiuokite pagal išsiuntimo datą" - kodėl to nepakanka
Dažniausias patarimas - pakeisti rūšiavimą iš „gavimo" datos į „išsiuntimo" datą el. pašto kliente. Tai iš tiesų pakeičia rodymo tvarką, bet netaiso pagrindinių duomenų. Paieškos rezultatuose vis tiek rodoma klaidinga data. Kalendoriaus integracijos, atitikties įrankiai ir automatizuotos darbo eigos, priklausančios nuo gavimo datos, toliau veikia neteisingai. Be to, naudotojai turi keisti šį nustatymą kiekviename įrenginyje ir kiekviename aplanke.
Pakartotinė migracija - brangi ir rizikinga
Kai kurie administratoriai svarsto galimybę pakartoti migraciją, tikėdamiesi išvengti datų problemos antruoju bandymu. Šis būdas yra brangus (500-5000 EUR, priklausomai nuo pašto dėžučių skaičiaus), užima daug laiko ir yra rizikingas. Antra migracija sukuria tą pačią „Received" antraštės problemą, dvigubina duomenų praradimo riziką ir reikalauja reikšmingos prastovos. Pakartotinė migracija neišsprendžia datų problemos, nebent migracijos įrankis būtų iš esmės pakeistas.
Rankinis antraščių redagavimas - reikia serverio prieigos
Techniškai taisymas apima migracijos „Received" antraštės pašalinimą iš kiekvieno el. laiško. Tačiau tai daryti rankiniu būdu reikalauja tiesioginės prieigos prie serverio, el. pašto antraščių struktūros žinių ir individualių scenarijų. 10 000 el. laiškų pašto dėžutėje rankinis redagavimas yra nepraktiškas ir pavojingai linkęs į klaidas. S/MIME pasirašyti el. laiškai, PGP šifruoti pranešimai, sudėtinės dalių struktūros su įdėtomis MIME ribomis, Content-Transfer-Encoding problemos, ne ASCII antraštės (RFC 2047), per didelės prikabintos bylos: kiekvienas iš šių atvejų gali priversti paprastą scenarijų negrįžtamai sugadinti duomenis. Kaip patvirtinti, kad 10 000 pataisytų el. laiškų yra nesugadinti? To padaryti neįmanoma be specialiai tam sukurtos patikros sistemos.
Tikrasis sprendimas - atkurti originalias datas
Teisingas būdas - identifikuoti migracijos artefaktus kiekvieno el. laiško antraščių grandinėje ir taikyti tikslines korekcijas, kurios atkuria originalią chronologinę tvarką visuose el. pašto klientuose. Tai nėra paprastas antraštės redagavimas. Procesas apima RFC atitikties patvirtinimą, pranešimo struktūros išsaugojimą ir migracijos įrankių parašų atitikimą iš žinomų įrankių profilių duomenų bazės.
Kaip Redate.io taiso šią problemą
Redate.io prisijungia prie pašto dėžutės („Google Workspace", „Microsoft 365" ar bet kurio IMAP serverio) ir analizuoja kiekvieną el. laišką, kad identifikuotų pranešimus, paveiktus migracijos antraščių. Analizė yra nemokama ir parodo tiksliai, kiek el. laiškų yra paveikti, prieš bet kokį mokėjimą.
Kiekvienam paveiktam el. laiškui Redate.io nuosavybinis taisymo variklis praleidžia pranešimą per daugiapakopį analizės konvejerį. Variklis taiko parašų atitikimą šimtams žinomų migracijos įrankių profilių, sukurtų apdorojant didelius realių el. pašto duomenų kiekius. Jis tvarko kodavimo problemas, sudėtines struktūras, įdėtus priedus ir dešimtis specialių atvejų, kurie priverstų „pasidaryk pats" scenarijų sugadinti duomenis (ne tas atradimas, kurį norėtumėte padaryti pirmadienio rytą). Kiekvienas pataisytas el. laiškas praeina vientisumo patikrą prieš užbaigimą. Originalus pranešimas perkeliamas į matomą aplanką „Redate.io - Originals" (neištrinamas) ir saugomas 30 dienų.
Rezultatas? El. laiškai rodo teisingas originalias datas visuose klientuose. Rūšiavimas vėl veikia. Pašto dėžutės chronologinė istorija atkurta.
Dažnai užduodami klausimai
Ar galima pataisyti datas praėjus mėnesiams po migracijos?
Taip. Originali „Date" antraštė išsaugoma el. laiško viduje nepriklausomai nuo to, kada buvo atlikta migracija. Redate.io gali pataisyti el. laiškų datas praėjus savaitėms, mėnesiams ar net metams po migracijos. Taisymas veikia tol, kol originalios el. laiško antraštės yra nepažeistos.
Ar datų taisymas ištrins mano el. laiškus?
Ne. Redate.io niekada netrina el. laiškų. Originalūs pranešimai perkeliami į matomą aplanką „Redate.io - Originals" pašto dėžutėje, kur jie lieka pasiekiami 30 dienų. Kiekvienas pataisytas el. laiškas patikrinamas lyginant su originalu prieš proceso užbaigimą. Jei patikra nepavyksta kuriam nors pranešimui, originalas lieka nepakeistas.
Ar tai veikia su bendrinamomis pašto dėžutėmis?
Taip. Redate.io veikia su bendrinamomis pašto dėžutėmis „Google Workspace" ir „Microsoft 365" aplinkose. Bendrinamoms dėžutėms reikalinga administratoriaus lygio prieiga ryšiui autorizuoti. Procesas identiškas asmeninėms dėžutėms: analizė, taisymas, patikra.
Pasirengę atkurti teisingas datas? Paleiskite nemokamą analizę ir sužinokite, kiek el. laiškų yra paveikti kiekvienoje pašto dėžutėje.