Popravite imapsync datume e-pošte

Obljuba --syncinternaldates (in kje se ustavi)

Pognali ste ukaz imapsync. Vključili ste --syncinternaldates, ker ste prebrali dokumentacijo in ste skrbni. Migracija se konča, dnevnik pravi, da je bilo vse preneseno, nič napak. Nato odprete nabiralnik v Outlooku in vsako e-poštno sporočilo prikazuje včerajšnji datum.

To je ena najpogostejših frustracij z imapsync in bega sistemske administratorje vsaj od leta 2017. Zastavica --syncinternaldates naj bi ohranila IMAP INTERNALDATE med migracijo. In to dejansko naredi: vsaki kopiji dodeli interni datum, ki ga hrani izvorni strežnik. Prav tam pa je skrita past.

imapsync je odprtokodno orodje, napisano v Perlu, avtor je Gilles Lamiral, in je resnično dobro v tem, kar dela. Obravnava IMAP-na-IMAP prenose nabiralnikov z ravnjo zanesljivosti, ki jo večina komercialnih orodij zavida. Toda imapsync lahko prekopira le datume, ki jih najde, in tu se stvari zapletejo.

Kako IMAP datumi dejansko delujejo

Obstajajo trije različni "datumi" pri vsakem e-poštnem sporočilu in večina ljudi (vključno z nekaterimi IT administratorji) jih meša:

Glava Date: (RFC 2822) - datum, ki ga je e-poštni odjemalec pošiljatelja odtisnil na sporočilo ob sestavljanju. Živi znotraj telesa sporočila in poštni strežniki ga nikoli ne spremenijo.
Glave Received: - vsak poštni strežnik, ki obdela sporočilo, doda eno s svojim časovnim žigom. Tvorijo verigo od pošiljatelja do prejemnika. Najnovejša glava Received je tista, ki jo nekateri e-poštni odjemalci uporabijo za prikaz.
INTERNALDATE - časovni žig na strani IMAP strežnika, ki nadzoruje razvrstitev sporočil v nabiralniku. Nastavi se, ko je sporočilo prvič shranjeno prek IMAP APPEND.

Ko imapsync preseli sporočilo, ga prebere z izvornega strežnika (vključno z njegovim INTERNALDATE) in ga zapiše na ciljni strežnik z uporabo IMAP APPEND. Zastavica --syncinternaldates pove imapsync, naj posreduje izvorni INTERNALDATE ciljnemu strežniku med APPEND.

Tukaj je dobra novica: Microsoft 365, Outlook.com in Gmail ohranijo datum, ki ga prejmejo. Ko so torej datumi napačni, je težava drugje.

Zakaj so datumi lahko še vedno napačni

Specifikacija IMAP (RFC 3501) pravi, da če je datum-čas podan z ukazom APPEND, bi ga strežnik MORAL uporabiti. "MORAL" v jeziku RFC pomeni "storite to, razen če imate dober razlog, da ne". Microsoft 365, Outlook.com in Gmail to počnejo: kopija, ki nosi svoj prvotni datum, ta datum tudi obdrži.

imapsync pa dejansko posreduje datum, ki ga za vsako sporočilo hrani IZVORNI strežnik, ne datuma, ko je bila e-pošta poslana. Pri zdravem nabiralniku se oba ujemata. Pri nabiralniku, ki je bil že enkrat migriran ali obnovljen iz varnostne kopije, lahko izvorni strežnik hrani datum tiste prejšnje operacije, in imapsync ga prekopira takšnega, kot je.

Gmail je posebnost samo takrat, ko kopija poteka prek Gmailovega lastnega API-ja za uvoz namesto prek IMAP: ta API doda vrstico Received:, datirano z dnem kopiranja, in Outlook lahko prikaže ta datum. imapsync govori IMAP, zato nanj to ne vpliva.

Dovecot in Cyrus, dva najpogostejša odprtokodna IMAP strežnika, prav tako ohranita datum iz APPEND. Ne glede na cilj je torej vprašanje vedno enako: kateri datum je hranil izvorni strežnik?

Pogoste napake v ukazni vrstici imapsync, ki pokvarijo datume

Poleg izvornih datumov administratorji pogosto naredijo napako z možnostmi ukazne vrstice imapsync ali krivijo napačne od njih. Tukaj so napake, ki jih najpogosteje vidim:

Kopiranje iz vira, kjer so bili datumi že napačni

--syncinternaldates je privzeto vključena: imapsync vsaki kopiji dodeli interni datum, ki ga hrani izvorni strežnik (dokumentacija pravi: "Sets the internal dates on host2 as the same as host1"). Če je izvorni nabiralnik sam rezultat prejšnje migracije ali obnovitve, so njegovi interni datumi morda že datumi tiste operacije, in imapsync zvesto prekopira napačen datum. To je najpogostejši vzrok in najlažje ga je spregledati, ker dnevnik prikazuje dva enaka datuma.

Uporaba --syncinternaldates z --addheader

Nekateri vodniki priporočajo uporabo --addheader za vstavljanje prilagojene glave med migracijo. Dodajanje glave spremeni sporočilo (ena vrstica več na vrhu), ne pa datuma, ki ga posreduje imapsync, zato to ne pojasni napačnih datumov. Kopija zgolj ni več identična izvirniku, kar je pomembno, če ju primerjate.

Mešanje --minage in --maxage z ohranjanjem datumov

Zastavici --minage in --maxage filtrirata, katera sporočila se preselijo na podlagi starosti. Ne vplivata na obravnavo datumov na cilju. Videl sem administratorje, ki so ure porabili za prilagajanje teh zastavic v prepričanju, da bodo popravile težavo z datumi. Ne bodo.

Krivda TLS za premaknjene datume

Prek TLS (--ssl1, --ssl2) vzpostavitev povezav doda zakasnitev, in pri velikih migracijah (50.000+ sporočil) se ta sešteje v ure. Na datume to ne vpliva: vsaka kopija nosi datum, ki ga posreduje imapsync, ne glede na to, kdaj dejansko pristane na cilju.

Branje dnevnikov imapsync: kaj izpis dejansko pove

imapsync ustvarja podrobne dnevnike, kar je odlično. Toda izpis dnevnika je lahko zavajajoč, ko gre za datume.

Tipična vrstica uspešnega prenosa izgleda takole:

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

To je eden najbolj frustrirajočih vidikov odpravljanja težav z datumi: čist dnevnik, dva enaka datuma, in vseeno napačen datum v Outlooku, ker je bila napaka tam še preden je imapsync sploh stekel. In Microsoft 365, Outlook.com in Gmail vsi ohranijo datum, ki ga prejmejo. Toda dva enaka datuma dokazujeta le, da je kopija zvesta IZVORU: če je bil izvorni datum že napačen, oba stolpca kažeta isti napačen datum.

Želite preveriti, kaj se je dejansko zgodilo? Po migraciji se povežite s ciljnim strežnikom z IMAP odjemalcem in preverite INTERNALDATE neposredno:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Če vrnjeni datum ni datum, ko je bila e-pošta poslana, poglejte isto sporočilo na viru: tam boste našli isti napačen datum. Dnevnik vam ni lagal, prekopiral je tisto, kar je prejel.

Obsežne migracije imapsync: kjer se težave z datumi pomnožijo

Migracija posameznega nabiralnika z imapsync je nadležna, ko se datumi pokvarijo. Toda MSP-ji in IT oddelki, ki poganjajo imapsync čez stotine nabiralnikov, se soočajo s povsem drugačnim obsegom težave.

Zamislite si tipičen scenarij podjetniške migracije. Selite 200 nabiralnikov s strežnika Zimbra na Microsoft 365. Napišete ovijalno skripto, ki gre skozi CSV uporabnikov in kliče imapsync za vsakega. Migracija teče čez vikend. V ponedeljek zjutraj imate 200 nabiralnikov s pokvarjenimi datumi in okrog 1,2 milijona sporočil, ki prikazujejo časovni žig migracije.

Ali lahko znova poženete imapsync, da to popravite? --dry pa le simulira prenos: pokaže datume, ki bi jih imapsync posredoval, ne pa, ali so to datumi, ko je bila e-pošta dejansko poslana. Nič vas ne opozori, da so izvorni datumi že napačni. In če so bili težava izvorni datumi, jih drugi zagon preprosto znova prekopira enako napačne.

Popravki po domače in njihove omejitve

Če iščete po forumih in poštnih seznamih (seznam imapsync-devel na SourceForge je še vedno aktiven od začetka 2026), boste našli predloge od ustvarjalnih do nevarnih.

Nekateri predlagajo uporabo Perl enovrstičnice za neposredno spremembo INTERNALDATE na ciljnem strežniku. Drugi priporočajo izvoz vseh sporočil v obliko mbox, manipulacijo datumov in ponovni uvoz. Nekateri so napisali Python skripte, ki uporabljajo imaplib za prenos, spremembo in ponovno vstavljanje sporočil.

Vsi ti pristopi delijo enake temeljne težave. Kako obravnavate S/MIME podpisana sporočila brez kvarjenja podpisa? Kaj z večdelnimi MIME strukturami z ugnezdenimi mejami? Ne-ASCII glavami, kodiranimi z RFC 2047? PGP šifriranimi sporočili, kjer ne morete niti pregledati vsebine? Skripta, ki obdela 50 testnih sporočil v razvojnem okolju, se bo zataknil pri robnih primerih v produkcijskem nabiralniku s 30.000 sporočili.

In največje vprašanje, ki ga nihče ne postavi, dokler ni prepozno: kako preverite, da je vsako spremenjeno sporočilo še vedno nedotaknjeno?

Kako Redate.io popravi imapsync težave z datumi

Izvorna glava Date: je po migraciji imapsync vedno nedotaknjena. imapsync zvesto prenese surovo sporočilo; napačen datum se skriva v metapodatkih, ki jih je kopija prejela, ne v sporočilu samem. Ta izvorna glava je tisto, kar omogoča popravek.

Redate.io se neposredno poveže z nabiralnikom (Google Workspace, Microsoft 365 ali kateri koli IMAP strežnik), pregleda e-pošto z anomalijami datumov in uporabi ciljano korekcijo metapodatkov prek lastniškega cevovoda za analizo verige glav in rekonstrukcijo datumov. Ni mu treba vedeti, s katerim orodjem je bila migracija opravljena: poišče e-pošto, katere prikazani datum se ne ujema z njenim prvotnim datumom.

Vsako popravljeno sporočilo se preverja posamezno: celovitost sporočila, ohranjanje prilog, uvrstitev v mapo, niti, oznake. Izvirniki se hranijo v vidni rezervni mapi Redate.io - Originals do trenutka, ko jih izbrišete sami. Če je kaj videti narobe, je vrnitev na en klik.

Brezplačen pregled se poveže z nabiralnikom, prepozna vsako e-pošto z anomalijo datuma in poroča natančno število in ceno. Brez kreditne kartice, brez nameščanja programske opreme. Za posebnosti vaše platforme:

Redate.io deluje tudi na migracijah, ki so se zgodile pred meseci ali leti. Glava Date: ne zastara in prav tako ne zmožnost popraviti, kar je šlo narobe.

Ste migrirali z imapsync in ostali z napačnimi datumi? Zaženite brezplačen pregled, da vidite natančno, koliko sporočil je prizadetih.

imapsync ni ohranil datumov? Kako jih popraviti