Kodėl imapsync populiarus (ir kodėl datos vis tiek sugenda)
imapsync yra etaloninis el. pašto migracijos įrankis „Linux" sistemų administratoriams, prieglobos paslaugų teikėjams ir visiems, kurie renkasi atvirojo kodo sprendimus. Sukurtas Gilles Lamiral, imapsync aktyviai palaikomas nuo 2001 m. ir buvo naudotas milijonams pašto dėžučių migracijų visame pasaulyje. Jis palaiko praktiškai visus IMAP serverius: Dovecot, Courier, Cyrus, Zimbra, Exchange, Gmail ir dešimtis kitų.
imapsync turi reputaciją kaip išsamus ir konfigūruojamas. Administratoriai vertina jo detalų valdymą - kuriuos aplankus migruoti, dublikatų tvarkymą ir aplankų pavadinimų susiejimą tarp skirtingų IMAP serverių. Tačiau nepaisant viso šio valdymo, viena problema išlieka: el. laiškų datos dažnai nėra išsaugomos po imapsync migracijos. Naudotojai atidaro savo pašto dėžutę po migracijos ir mato, kad kiekvienas el. laiškas rodo migracijos datą. Tai erzina, ypač todėl, kad imapsync turėtų teisingai tvarkyti datas.
Kaip imapsync tvarko INTERNALDATE
INTERNALDATE išsaugojimo bandymas
imapsync iš tiesų bando išsaugoti kiekvieno el. laiško INTERNALDATE migracijos metu. INTERNALDATE yra laiko žyma, kurią IMAP serveris saugo kaip metaduomenis kiekvienam pranešimui, atskirai nuo el. laiško antraščių. Kai imapsync kopijuoja pranešimą iš šaltinio į paskirties vietą, jis nuskaito šaltinio serverio INTERNALDATE ir perduoda ją paskirties serveriui IMAP APPEND komandoje.
Teoriškai tai turėtų išsaugoti originalią datą. Praktikoje rezultatas priklauso nuo paskirties serverio elgesio ir nuo to, kaip el. pašto klientai interpretuoja skirtingus su datomis susijusius laukus pranešime.
„Received" antraštės problema
Net kai imapsync sėkmingai išsaugo INTERNALDATE, paskirties el. pašto serveris prideda naują „Received" antraštę prie kiekvieno pranešimo APPEND operacijos metu. Ši „Received" antraštė turi esamą laiko žymą - migracijos datą. El. pašto klientai kaip „Outlook", „Apple Mail" ir „Thunderbird" nustato rodomą „gavimo" datą skaitydami aukščiausią „Received" antraštę, o ne INTERNALDATE. Todėl nepaisant imapsync pastangų išsaugoti INTERNALDATE, matoma data daugumoje klientų vis tiek klaidinga.
Būtent šis esminis neatitikimas sukelia painiavą. imapsync išsaugo vieną datos reikšmę (INTERNALDATE), bet el. pašto klientai rodo kitą („Received" antraštės laiko žymą). Techniniam šio mechanizmo paaiškinimui žr. kodėl el. laiškai rodo klaidingą datą po IMAP migracijos.
imapsync DUK klaidingas įspūdis
imapsync dokumentacija ir DUK aptaria datų problemą, bet pateikia ją kaip neišvengiamą apribojimą. DUK siūlo, kad „datos gali būti neišsaugotos" IMAP migracijos metu ir numano, kad tiesiog taip veikia IMAP protokolas. Nors tiesa, kad IMAP protokolas reikalauja, jog serveriai pridėtų „Received" antraštes pranešimų įterpimo metu, DUK sukuria įspūdį, kad problema yra nuolatinė ir nepataisoma.
Tai nėra tikslu. Migracijos metu pridėtos „Received" antraštės gali būti identifikuotos ir pašalintos vėliau, atkuriant originalų datos rodymą el. pašto klientuose. Originali „Date" antraštė (kuri fiksuoja, kada el. laiškas buvo pradžioje išsiųstas) visada yra išsaugoma imapsync ir naudojama kaip teisingos datos atskaitos taškas.
imapsync migracijos antraštės identifikavimas
Kaip atrodo antraštė
imapsync pats neprideda „Received" antraštės - tai daro paskirties IMAP serveris. Antraštė, pridėta imapsync migracijos metu, paprastai atrodo kaip standartinė paskirties serverio IMAP įterpimo antraštė. Pavyzdžiui, migruojant į Dovecot serverį, antraštė galėtų atrodyti taip:
Received: from localhost by mail.example.com;
Wed, 15 Jan 2025 09:14:22 +0100
Pagrindinis identifikatorius - ši „Received" antraštė yra aukščiausia grandinėje, jos laiko žyma atitinka imapsync migracijos vykdymo datą, ir ji paprastai nurodo „localhost" arba paskirties serverio pavadinimą, o ne išorinį el. pašto serverį.
Datų palyginimas
Norėdami patvirtinti problemą, palyginkite aukščiausios „Received" antraštės laiko žymą su el. laiško „Date" antrašte. Jei „Received" antraštė rodo 2025 m. sausį, bet „Date" antraštė rodo 2020 m. kovą, migracijos „Received" antraštė yra klaidingo datos rodymo priežastis.
Kodėl dažnos imapsync parinktys neišsprendžia problemos
Vėliavėlė --syncinternaldates
imapsync siūlo vėliavėlę --syncinternaldates, kuri nustato paskirties serverio INTERNALDATE pagal el. laiško „Date" antraštę. Tai naudinga, kai šaltinio serverio INTERNALDATE jau klaidinga, bet tai neužkerta kelio paskirties serveriui pridėti „Received" antraštę. Matoma data „Outlook" ir kituose klientuose lieka migracijos data, nepriklausomai nuo INTERNALDATE reikšmės.
Parinktis --addheader
imapsync gali pridėti individualias antraštes pranešimams migracijos metu, bet negali užkirsti kelio paskirties serveriui pridėti savo „Received" antraštę. IMAP protokolas reikalauja, kad serveriai fiksuotų įterpimo laiko žymą, ir jokia imapsync parinktis negali pakeisti šio serverio lygio elgesio.
Po migracijos scenarijai
Kai kurie administratoriai rašo individualius po migracijos scenarijus nepageidaujamoms „Received" antraštėms pašalinti. Tai atrodo protinga, ypač žmonėms, kurie pasirinko imapsync (komandinės eilutės mėgėjams). Tačiau realybė kur kas sudėtingesnė nei paieška-pakeitimas antraštės tekste. Kas nutinka, kai scenarijus aptinka S/MIME pasirašytą el. laišką? Ar daugiadlį pranešimą su įdėtomis MIME ribomis ir base64 koduotais priedais? Ar antraštę su ne ASCII simboliais, koduotais pagal RFC 2047? Vienas neteisingai padėtas baitas MIME riboje gali tyliai sugadinti visą pranešimą, sunaikindamas priedus ar padarydamas el. laišką neįskaitomą. O kaip patvirtinti, kad 10 000 pataisytų el. laiškų visi yra nesugadinti? Tūkstančiams el. laiškų per kelias pašto dėžutes, „pasidaryk pats" scenarijus kelia nemažą riziką.
imapsync datų taisymas su Redate.io
Kaip Redate.io tvarko imapsync migracijas
Redate.io nuosavybinis taisymo variklis specialiai sukurtas šios kategorijos problemai. Prisijungus prie pašto dėžutės, Redate.io analizuoja kiekvieną el. laišką ir praleidžia kiekvieną pranešimą per daugiapakopį analizės konvejerį. imapsync migracijoms Redate.io aptinka serverio įterptą „Received" antraštę taikydamas parašų atitikimą šimtams žinomų migracijos profilių, analizuodamas visą antraščių grandinę ir kryžmiškai tikrindamas laiko žymas su originalia „Date" antrašte.
Tai nėra paprastas antraštės redagavimas. Taisymo variklis tvarko RFC atitikties patvirtinimą, pranešimo struktūros išsaugojimą (įskaitant multipart/alternative struktūras, įdėtus priedus ir Content-Transfer-Encoding variacijas) ir skaitmeninių parašų aptikimą. El. laiškai su S/MIME ar PGP parašais automatiškai identifikuojami ir apdorojami tinkamai parašų vientisumui išsaugoti.
Kas gaunama po taisymo
Kiekvienas pataisytas el. laiškas rodo originalią gavimo datą visuose el. pašto klientuose. Chronologinė tvarka atkurta. Kiekviena korekcija praeina vientisumo patikrą prieš užbaigimą. Originalus pranešimas perkeliamas į aplanką „Redate.io - Originals" ir saugomas 30 dienų kaip apsauginis tinklas.
Suderinamumas su visais paskirties serveriais
Kadangi imapsync naudojamas migracijai į praktiškai bet kurį IMAP serverį, Redate.io palaiko tą patį paskirties platformų spektrą. Nesvarbu, ar imapsync migracija buvo nukreipta į Dovecot, Courier, Cyrus, Zimbra, „Google Workspace", „Microsoft 365" ar bet kurį kitą IMAP serverį - Redate.io prisijungia ir taiso datas.
Kaip pataisyti datas po imapsync migracijos
Prisijungti prie pašto dėžutės
Prisijunkite prie Redate.io ir pridėkite pašto dėžutę. „Google Workspace" ar „Microsoft 365" atveju naudokite administratoriaus delegavimo parinktį. Kitiems IMAP serveriams (dažniems imapsync scenarijuose) įveskite serverio adresą, naudotojo vardą ir slaptažodį. Redate.io prisijungia per standartinį IMAP.
Nemokama analizė
Paleiskite nemokamą analizę paveiktiems el. laiškams identifikuoti. Analizės ataskaita rodo bendrą el. laiškų skaičių, kiek turi klaidingą datą ir kokia migracijos data buvo aptikta. Ši analizė nieko nekainuoja ir suteikia aiškų vaizdą prieš bet kokį įsipareigojimą.
Taisyti ir patikrinti
Pasirinkite planą pagal paveiktų el. laiškų skaičių ir paleiskite taisymą. Eiga matoma realiu laiku. Po užbaigimo patikrinkite rezultatus peržiūrėdami el. laiškų datas savo kliente. Datos turėtų būti grįžusios į savo vietas.
imapsync taisymo vadovai pagal platformą
Dažnai užduodami klausimai
Ar reikia naudoti imapsync --syncinternaldates prieš naudojant Redate.io?
Tai nebūtina. Redate.io nustato teisingą INTERNALDATE taisymo proceso metu, nepriklausomai nuo esamos reikšmės. Nesvarbu, ar imapsync išsaugojo originalią INTERNALDATE, ar ne - Redate.io išveda teisingą reikšmę iš originalios „Date" antraštės.
Ar galima pataisyti datas šaltinio serveryje prieš migruojant su imapsync?
Jei šaltinio serveris jau turi klaidingas datas (dėl ankstesnės migracijos), Redate.io gali jas pataisyti prieš ar po imapsync migracijos. Tačiau datų taisymas paskirties serveryje po migracijos yra dažniausias ir praktiškiausias būdas.
Kiek el. laiškų Redate.io gali apdoroti?
Redate.io tvarko bet kokio dydžio pašto dėžutes. Planai prieinami iki 100 000 el. laiškų vienai pašto dėžutei. Organizacijoms su daugeliu dėžučių Redate.io siūlo kiekio nuolaidas.
imapsync migracija sugadino datas? Paleiskite nemokamą analizę ir sužinokite, kiek el. laiškų paveikta, bei pataisykite juos su Redate.io.