Pataisykite imapsync el. pašto datas

Pažadas --syncinternaldates (ir kur jis sustoja)

Paleidote imapsync komandą. Įtraukėte --syncinternaldates, nes perskaitėte dokumentaciją ir esate toks atsargus. Migracija baigiasi, žurnalas rodo, kad visi el. laiškai perkelti, nulis klaidų. Tada atidarote pašto dėžutę Outlook programoje ir kiekvienas el. laiškas rodo vakarykštę datą.

Tai vienas dažniausių nusivylimų dirbant su imapsync, ir jis klaidina sistemos administratorius bent nuo 2017 metų. Vėliavėlė --syncinternaldates turėtų išsaugoti IMAP INTERNALDATE migracijos metu. Ir ji tai daro: kiekvienai kopijai suteikia vidinę datą, kurią laiko šaltinio serveris. Tai ir yra spąstai.

imapsync yra atviro kodo Perl įrankis, sukurtas Gilles Lamiral, ir jis iš tikrųjų puikiai atlieka savo darbą. Jis tvarko IMAP į IMAP pašto dėžučių perkėlimus su tokiu patikimumo lygiu, kurio dauguma komercinių įrankių pavydi. Bet imapsync gali nukopijuoti tik tas datas, kurias randa, ir čia viskas tampa sudėtinga.

Kaip IMAP datos iš tikrųjų veikia

Kiekviename el. laiške dalyvauja trys skirtingos "datos", ir dauguma žmonių (įskaitant kai kuriuos IT administratorius) jas sumaišo:

Date: antraštė (RFC 2822) - data, kurią siuntėjo el. pašto klientas uždėjo pranešimui, kai jis buvo parašytas. Ji yra pranešimo turinyje ir pašto serveriai jos niekada nekeičia.
Received: antraštės - kiekvienas pašto serveris, apdorojantis pranešimą, prideda vieną su savo laiko žyma. Jos sudaro grandinę nuo siuntėjo iki gavėjo. Viršutinė (naujausia) Received antraštė yra ta, kurią kai kurie el. pašto klientai naudoja rodymui.
INTERNALDATE - IMAP serverio pusės laiko žyma, kuri nustato, kaip pranešimai rūšiuojami pašto dėžutėje. Ji nustatoma, kai pranešimas pirmą kartą įrašomas per IMAP APPEND.

Kai imapsync migruoja pranešimą, jis nuskaito pranešimą iš šaltinio serverio (įskaitant jo INTERNALDATE) ir įrašo jį į paskirties serverį naudodamas IMAP APPEND. Vėliavėlė --syncinternaldates nurodo imapsync perduoti šaltinio INTERNALDATE paskirties serveriui APPEND metu.

Yra ir gera žinia: Microsoft 365, Outlook.com ir Gmail išsaugo tą datą, kuri jiems perduota. Todėl kai datos rodomos neteisingai, problema yra kitur.

Kodėl datos vis tiek gali būti neteisingos

IMAP specifikacija (RFC 3501) sako, kad, jei data ir laikas nurodyti su APPEND komanda, serveris TURĖTŲ juos naudoti. "TURĖTŲ" RFC kalba reiškia "darykite tai, nebent turite gerą priežastį nedaryti". Microsoft 365, Outlook.com ir Gmail tą daro: kopija, kuri turi savo pradinę datą, ją ir išsaugo.

Tačiau tai, ką imapsync perduoda, yra data, kurią ŠALTINIO serveris laiko kiekvienam pranešimui, o ne data, kada el. laiškas buvo išsiųstas. Sveikoje pašto dėžutėje šios dvi datos sutampa. Dėžutėje, kuri jau buvo kartą migruota arba atkurta iš atsarginės kopijos, šaltinis gali laikyti ankstesnės operacijos datą, ir imapsync tiesiog nukopijuoja ją tokią, kokia yra.

Gmail yra atskiras atvejis tik tada, kai kopija vyksta per Gmail nuosavą importo API, o ne per IMAP: ta API prideda Received: eilutę, pažymėtą kopijavimo diena, ir Outlook gali rodyti tą datą. imapsync naudoja IMAP protokolą, todėl jam tai neturi įtakos.

Dovecot ir Cyrus, du dažniausiai naudojami atviro kodo IMAP serveriai, taip pat išsaugo datą iš APPEND. Taigi, kokia bebūtų paskirties vieta, klausimas tas pats: kokią datą laikė šaltinis?

Dažnos imapsync komandų eilutės klaidos, dėl kurių datos tampa neteisingos

Be šaltinio datų problemos, administratoriai dažnai suklumpa ant imapsync komandų eilutės parametrų arba kaltina netinkamus. Čia dažniausios klaidos, kurias pastebiu:

Kopijavimas iš šaltinio, kurio datos jau buvo neteisingos

--syncinternaldates yra įjungta pagal nutylėjimą: imapsync kiekvienai kopijai suteikia vidinę datą, kurią laiko šaltinio serveris (jo dokumentacijoje: "Sets the internal dates on host2 as the same as host1"). Jei pati šaltinio pašto dėžutė yra ankstesnės migracijos ar atkūrimo rezultatas, jos vidinės datos gali būti tos operacijos datos, ir imapsync ištikimai nukopijuoja neteisingą datą. Tai dažniausia priežastis, ir lengviausia jos nepastebėti, nes žurnale rodomos dvi identiškos datos.

--syncinternaldates naudojimas su --addheader

Kai kurie vadovai rekomenduoja naudoti --addheader, kad migracijos metu būtų įterpta pasirinktinė antraštė. Antraštės pridėjimas pakeičia pranešimą (viena papildoma eilutė viršuje), bet nepaveikia datos, kurią perduoda imapsync, todėl tai nepaaiškina neteisingų datų. Kopija tiesiog nebėra identiška pradiniam laiškui, kas svarbu, jei juos lyginate.

--minage ir --maxage painiojimas su datų išsaugojimu

Vėliavėlės --minage ir --maxage filtruoja, kuriuos pranešimus migruoti pagal jų amžių. Jos neturi įtakos tam, kaip datos tvarkomos paskirties vietoje. Esu matęs administratorius, valandų valandas derinančius šias vėliavėles, tikintis, kad tai pataisys datų problemą. Nepataisys.

TLS kaltinimas dėl pasislinkusių datų

Naudojant TLS (--ssl1, --ssl2), ryšių užmezgimas prideda vėlinimą, o didelėje migracijoje (50 000+ pranešimų) tai susisumuoja į valandas. Tai neturi įtakos datoms: kiekviena kopija turi tą datą, kurią perdavė imapsync, nesvarbu, kokiu momentu ji faktiškai atkeliauja.

imapsync žurnalų skaitymas: ką išvestis iš tikrųjų rodo

imapsync generuoja detalius žurnalus, ir tai puiku. Bet žurnalo išvestis, kai kalba pasisuka apie datas, gali klaidinti.

Tipinė sėkmingo perkėlimo eilutė atrodo taip:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Abi datos sutampa. Tai reiškia, kad imapsync nusiuntė teisingą INTERNALDATE paskirties vietai. Ir Microsoft 365, Outlook.com bei Gmail visi išsaugo tą datą, kuri jiems perduota. Bet dvi identiškos datos tik įrodo, kad kopija ištikima ŠALTINIUI: jei šaltinio data buvo jau neteisinga, abu stulpeliai rodo tą pačią neteisingą datą.

Norite patikrinti, kas iš tikrųjų nutiko? Po migracijos prisijunkite prie paskirties serverio su IMAP klientu ir patikrinkite INTERNALDATE tiesiogiai:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Jei grąžinta data nėra ta, kada el. laiškas buvo išsiųstas, pažiūrėkite tą pačią žinutę šaltinio pašto dėžutėje: rasite tą pačią neteisingą datą ir tenai. Žurnalas nemelavo, jis nukopijavo tai, kas jam buvo duota.

Tai vienas iš pačių erzinančių datų problemų derinimo aspektų: švarus žurnalo failas, dvi identiškos datos, o Outlook vis tiek rodo neteisingą datą, nes klaida buvo dar prieš imapsync paleidimą.

Didelio masto imapsync migracijos: kur datų problemos dauginasi

Vienos pašto dėžutės migracija su imapsync yra erzinanti, kai datos sugenda. Bet MSP ir IT skyriai, vykdantys imapsync per šimtus dėžučių, susiduria su visiškai kito mastelio problema.

Panagrinėkite tipinį įmonės migracijos scenarijų. Perkeliate 200 pašto dėžučių iš Zimbra serverio į Microsoft 365. Rašote apvalkalo scenarijų, kuris eina per vartotojų CSV sąrašą, kviesdamas imapsync kiekvienam. Migracija vyksta per savaitgalį. Pirmadienio rytą turite 200 dėžučių su neteisingomis datomis, ir apytiksliai 1,2 milijono el. laiškų iš viso rodo migracijos laiko žymą.

Ar galite iš naujo paleisti imapsync, kad tai pataisytumėte? Techniškai taip, bet imapsync praleis pranešimus, kurie paskirties vietoje jau egzistuoja (jis sukurtas idempotentiškas). Reikėtų --delete2, kad pašalintumėte paskirties pranešimus ir perkeltumėte juos iš naujo, o tai rizikinga gamybinėje pašto dėžutėje. Ir jei problema buvo šaltinio datos, antras paleidimas vėl nukopijuoja tas pačias neteisingas datas.

Kai kurie administratoriai bando mišrų metodą: pirmiausia paleisti imapsync su --dry testavimui, tada tikrąją migraciją. Bet --dry tik simuliuoja perkėlimą: ji rodo datas, kurias imapsync perduotų, o ne tai, ar tai yra datos, kada el. laiškai buvo išsiųsti. Niekas neįspėja, kad šaltinio datos jau yra neteisingos.

Savarankiški taisymai ir jų ribos

Jei ieškote forumuose ir pašto sąrašuose (imapsync-devel sąrašas SourceForge platformoje 2026-ųjų pradžioje vis dar aktyvus), rasite pasiūlymų nuo kūrybiškų iki pavojingų.

Kai kurie žmonės pataria naudoti vienaeilę Perl komandą, kad tiesiogiai pakeistų INTERNALDATE paskirties serveryje. Kiti rekomenduoja eksportuoti visus pranešimus į mbox formatą, keisti datas ir importuoti iš naujo. Keli yra parašę Python scenarijus, naudojančius imaplib pranešimams parsisiųsti, pakeisti ir įterpti iš naujo.

Visi šie metodai turi tas pačias esmines problemas. Kaip tvarkyti S/MIME pasirašytus pranešimus, nesugadinant parašo? O daugiadalykes MIME struktūras su įdėtomis ribomis? Ne-ASCII antraštes, koduotas su RFC 2047? PGP užšifruotus pranešimus, kurių turinio net negalima patikrinti? Scenarijus, sutvarkantis 50 testinių pranešimų kūrimo aplinkoje, užstrigs ties kraštutiniais atvejais 30 000 pranešimų gamybinėje dėžutėje.

Ir svarbiausias klausimas, kurio niekas neuždavė, kol nebuvo per vėlu: kaip patikrinti, kad kiekvienas pakeistas pranešimas tebėra nepažeistas? Kad priedai nebuvo sugadinti, kad gijos vis tiek veikia, kad 85 MB skaičiuoklė, kurią kažkas išsiuntė 2020 metais, išgyveno manipuliaciją?

(Jei kada bandėte analizuoti neapdorotas el. laiškų antraštes Perl kalba, žinote, kad tai ne pati ramiausia popietės veikla.)

Kaip Redate.io pataiso imapsync datų problemas

Pradinė Date: antraštė po imapsync migracijos visada yra nepaliesta. imapsync ištikimai perkelia neapdorotą pranešimą; neteisinga data yra kopijos gautuose metaduomenyse, o ne pačiame pranešime. Ta pradinė antraštė ir yra tai, kas leidžia pataisyti datą.

Redate.io jungiasi tiesiai prie pašto dėžutės (Google Workspace, Microsoft 365 ar bet kurio IMAP serverio), nuskaito el. laiškus su datų anomalijomis ir taiko tikslinę metaduomenų korekciją per Redate sukurtą antraščių grandinės analizės ir datų atkūrimo procesą. Jam nereikia žinoti, kuris įrankis vykdė migraciją: jis randa el. laiškus, kurių rodoma data nesutampa su pradine data.

Kiekvienas pataisytas el. laiškas tikrinamas individualiai: pranešimo vientisumas, priedų išsaugojimas, aplanko vieta, gijos, žymos. Pradiniai laiškai laikomi matomame Redate.io - Originals atsarginės kopijos aplanke ir lieka jame, kol jų patys nepašalinate. Jei kas nors atrodo netinkamai, atšaukti pakeitimus galima vienu paspaudimu.

Nemokamas nuskaitymas prisijungia prie pašto dėžutės, identifikuoja kiekvieną el. laišką su datos anomalija ir praneša tikslų skaičių ir kainą. Nereikia kredito kortelės, nereikia jokios programinės įrangos diegti. Jūsų platformos specifikai:

Redate.io taip pat veikia su migracijomis, kurios įvyko prieš mėnesius ar metus. Date: antraštė nesensta, kaip ir galimybė pataisyti tai, kas nutiko negerai.

Migravote su imapsync ir liko neteisingos datos? Paleiskite nemokamą nuskaitymą, kad sužinotumėte, kiek tiksliai el. laiškų yra paveikta.

imapsync neišsaugojo datų? Kaip jas pataisyti