Pataisykite imapsync el. pašto datas

Pažadas --syncinternaldates (ir kodėl jis neveikia)

Paleidote imapsync komandą. Įtraukėte --syncinternaldates, nes perskaitėte dokumentaciją ir esate atidūs. Perkėlimas baigiasi, žurnalas sako, kad viskas perkelti, nulis klaidų. Tada atidarote pašto dėžutę Outlook ir kiekvienas el. laiškas rodo vakarykštę datą.

Tai viena dažniausių frustacijų su imapsync ir klaidina sistemos administratorius bent jau nuo 2017 metų. Vėliavėlė --syncinternaldates turėtų išsaugoti IMAP INTERNALDATE perkėlimo metu. Ir techniškai ji bando. Bet "bando" šiame sakinyje neša daug svorio.

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 datų išsaugojimas nėra visiškai imapsync rankose, 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 ant pranešimo, kai jis buvo parašytas. Ji gyvena pranešimo turinyje ir pašto serveriai jos niekada nekeičia.
Received: antraštės - kiekvienas pašto serveris, kuris apdoroja pranešimą, prideda vieną su savo laiko žyma. Jos sudaro grandinę nuo siuntėjo iki gavėjo. Naujausia Received antraštė yra tai, ką kai kurie el. pašto klientai naudoja rodymui.
INTERNALDATE - laiko žyma IMAP serverio pusėje, kuri valdo, kaip pranešimai rūšiuojami dėžutėje. Ji nustatoma, kai pranešimas pirmą kartą išsaugomas per IMAP APPEND.

Kai imapsync perkelia pranešimą, jis nuskaito jį 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 per APPEND.

Problema ta: paskirties serveris neprivalo gerbti tos datos.

Kodėl paskirties serveriai ignoruoja INTERNALDATE

IMAP specifikacija (RFC 3501) sako, kad jei data-laikas pateiktas su APPEND komanda, serveris TURĖTŲ ją naudoti. "TURĖTŲ" RFC kalba reiškia "darykite tai, nebent turite gerą priežastį nedaryti". Kelios didelės el. pašto platformos nusprendė, kad turi gerą priežastį.

Microsoft 365 yra didžiausias kaltininkas. Kai pranešimas ateina per IMAP APPEND, Exchange transporto konvejeris jį pažymi nauja Received antrašte su dabartine data, tada nustato INTERNALDATE pagal tą pristatymo laiko žymą. Nesvarbu, kokią datą imapsync prašė. M365 serveris ją perrašo.

Google Workspace (Gmail) elgiasi kitaip, bet vis tiek gali sukelti problemų. Gmail IMAP implementacija daugeliu atvejų gerbia INTERNALDATE iš APPEND, bet prideda savo Received antraštę. Jei el. pašto klientas, kuris skaito dėžutę, teikia pirmenybę Received antraštėms prieš INTERNALDATE rodymui (o Outlook būtent tai daro), datos vis tiek atrodo neteisingos.

Dovecot ir Cyrus, du dažniausiai naudojami atviro kodo IMAP serveriai, paprastai gerbia INTERNALDATE iš APPEND. Taigi imapsync perkėlimai tarp dviejų Dovecot serverių paprastai teisingai išsaugo datas. Problemos prasideda, kai paskirties vieta yra prieglobos platforma su savo transporto apdorojimu.

Dažnos imapsync komandų eilutės klaidos, kurios sugadina datas

Visiškas --syncinternaldates pamiršimas

Vėliavėlė nėra įjungta pagal nutylėjimą. Jei paleisite pagrindinę imapsync --host1 šaltinis --host2 paskirties --user1 vartotojas --user2 vartotojas be jos, imapsync apskritai nebandys išsaugoti datų. Paskirties serveris naudos dabartinę laiko žymą kiekvienam pranešimui.

--syncinternaldates naudojimas su --addheader

Kai kurie vadovai rekomenduoja naudoti --addheader pasirinktinei antraštei įterpti perkėlimo metu. Jei pridedate antraštes, modifikuojate pranešimą, o tai gali paskatinti paskirties serverį jį laikyti "nauju" pranešimu ir atitinkamai pažymėti.

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

Vėliavėlės --minage ir --maxage filtruoja, kuriuos pranešimus perkelti pagal amžių. Jos neveikia datų apdorojimo paskirties vietoje. Mačiau administratorius, praleidžiančius valandas derindami šias vėliavėles, manydami, kad tai ištaisys datų problemą. Neištaisys.

SSL derybos, sukeliančios laiko žymų poslinkį

Perkeliant per TLS su --ssl1 ir --ssl2, ryšio nustatymas prideda vėlinimą. Dideliuose perkėlimuose (50 000+ pranešimų) šis vėlinimas kaupiasi. Nors jis nekeičia datų dienomis, gali sukelti, kad pranešimai, išsiųsti minučių intervalu, paskirties vietoje atsidurs su identiškomis laiko žymomis, prarasdami santykinę tvarką.

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

imapsync gamina detalius žurnalus, kas yra puiku. Bet žurnalo išvestis gali būti klaidinanti, kalbant apie datas.

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. Bet tai nereiškia, kad paskirties serveris tą datą iš tikrųjų išsaugojo. imapsync praneša apie tai, ko prašė, o ne tai, ką serveris priėmė.

Didelio masto imapsync perkėlimai: kur datų problemos dauginasi

Vienos pašto dėžutės perkėlimas su imapsync yra nemaloni, kai datos sugenda. Bet MSP ir IT skyriai, vykdantys imapsync per šimtus dėžučių, susiduria su visiškai kitu problemos mastu.

Įsivaizduokite tipinį įmonės perkėlimo scenarijų. Perkeliate 200 pašto dėžučių iš Zimbra serverio į Microsoft 365. Rašote apvalkalo scenarijų, kuris eina per vartotojų CSV, kviečia imapsync kiekvienam. Perkėlimas vyksta savaitgalį. Pirmadienio rytą turite 200 dėžučių su sugadintomis datomis ir apie 1,2 milijono el. laiškų, rodančių perkėlimo laiko žymą.

Savarankiški taisymai ir jų ribos

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

Kai kurie siūlo naudoti Perl vienaeilę INTERNALDATE modifikavimui tiesiogiai paskirties serveryje. Kiti rekomenduoja eksportuoti visus pranešimus į mbox formatą, manipuliuoti datatomis ir iš naujo importuoti. Kai kurie parašė Python scenarijus, naudojančius imaplib pranešimų parsisiuntimui, modifikavimui ir pakartotiniam įterpimui.

Visi šie požiūriai turi tas pačias esmines problemas. Kaip tvarkote S/MIME pasirašytus pranešimus nesugadindami parašo? O daugiadalykines MIME struktūras su įdėtinėmis ribomis? Ne-ASCII antraštes, koduotas RFC 2047? PGP šifruotus pranešimus, kur net negalite patikrinti turinio? Scenarijus, veikiantis su 50 bandomųjų pranešimų kūrimo aplinkoje, užstrigs ties kraštutiniais atvejais gamybinėje dėžutėje su 30 000 pranešimų.

Kaip Redate.io taiso imapsync datų problemas

Originali Date: antraštė po imapsync perkėlimo visada yra nepaliesta. imapsync ištikimai perkelia neapdorotą pranešimą; rodymo problemą sukelia paskirties serverio metaduomenų apdorojimas. Ta originali antraštė yra tai, kas daro korekciją galimą.

Redate.io tiesiogiai jungiasi prie pašto dėžutės (Google Workspace, Microsoft 365 ar bet kuris IMAP serveris), nuskaito el. laiškus su datų anomalijomis ir taiko tikslinę metaduomenų korekciją per nuosavą antraščių grandinės analizės ir datų rekonstrukcijos konvejerį. Korekcija tvarko specifinius modelius, kuriuos imapsync perkėlimai palieka, įskaitant būdingus Received antraščių parašus nuo paskirties serverių, kurie perrašė INTERNALDATE.

Kiekvienas ištaisytas el. laiškas tikrinamas individualiai: pranešimo vientisumas, priedų išsaugojimas, aplanko vieta, gijos, žymės. Originalai saugomi matomame Redate.io - Originals atsarginių kopijų aplanke 30 dienų.

Redate.io taip pat veikia su perkėlimais, įvykusiais prieš mėnesius ar metus. Date: antraštė nepasensta, kaip ir galimybė ištaisyti tai, kas nepavyko.

Perkėlėte su imapsync ir likote su neteisingais datumais? Paleiskite nemokamą nuskaitymą, kad pamatytumėte tiksliai, kiek el. laiškų paveikta.

imapsync neišsaugojo datų? Kaip jas pataisyti