Popravite imapsync datume e-pošte

Obljuba --syncinternaldates (in zakaj ne deluje)

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 tehnično to poskuša. Toda "poskuša" nosi veliko težo v tem stavku.

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 ohranjanje datumov ni v celoti v rokah imapsync, 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 težava: ciljni strežnik ni dolžan spoštovati tega datuma.

Zakaj ciljni strežniki ignorirajo INTERNALDATE

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". Več velikih e-poštnih platform se je odločilo, da imajo dober razlog.

Microsoft 365 je največji krivec. Ko sporočilo prispe prek IMAP APPEND, ga transportni cevovod Exchange odtisne z novo glavo Received s trenutnim datumom, nato nastavi INTERNALDATE na podlagi tega časovnega žiga dostave. Ni pomembno, kateri datum je imapsync zahteval. Strežnik M365 ga prepiše.

Google Workspace (Gmail) se obnaša drugače, a lahko še vedno povzroči težave. Gmailova implementacija IMAP v večini primerov spoštuje INTERNALDATE iz APPEND, toda doda lastno glavo Received. Če e-poštni odjemalec, ki bere nabiralnik, daje prednost glavam Received pred INTERNALDATE za prikaz (in Outlook to natanko počne), datumi še vedno izgledajo napačni.

Dovecot in Cyrus, dva najpogostejša odprtokodna IMAP strežnika, na splošno spoštujeta INTERNALDATE iz APPEND. Torej migracije imapsync med dvema strežnikoma Dovecot ponavadi pravilno ohranijo datume. Težave se začnejo, ko je cilj gostovana platforma z lastno transportno obdelavo.

Pogoste napake v ukazni vrstici imapsync, ki pokvarijo datume

Tudi ko bi ciljni strežnik sodeloval, administratorji pogosto naredijo napako z možnostmi ukazne vrstice imapsync. Tukaj so napake, ki jih najpogosteje vidim:

Pozaba --syncinternaldates v celoti

Zastavica ni privzeto vključena. Če poženete osnovni imapsync --host1 vir --host2 cilj --user1 uporabnik --user2 uporabnik brez nje, imapsync sploh ne poskuša ohraniti datumov. Ciljni strežnik uporabi trenutni časovni žig za vsako sporočilo. To je najpogostejši vzrok in najlažje ga je spregledati, ker imapsync vas ne opozori.

Uporaba --syncinternaldates z --addheader

Nekateri vodniki priporočajo uporabo --addheader za vstavljanje prilagojene glave med migracijo. Če dodajate glave, spreminjate sporočilo, kar lahko sproži, da ciljni strežnik to obravnava kot "novo" sporočilo in ga ustrezno odtisne. Interakcija med tema dvema zastavicama je slabo dokumentirana.

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.

SSL pogajanje, ki povzroča zamik časovnih žigov

Pri migraciji prek TLS z --ssl1 in --ssl2 vzpostavitev povezave doda zakasnitev. Pri velikih migracijah (50.000+ sporočil) se ta zakasnitev kopiči. Čeprav ne spremeni datumov za dneve, lahko povzroči, da sporočila, poslana z minutnim razmikom, prispejo z enakimi časovnimi žigi na cilj, s čimer izgubijo relativni vrstni red.

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

Oba datuma se ujemata. To pomeni, da je imapsync poslal pravilen INTERNALDATE na cilj. Toda to ne pomeni, da je ciljni strežnik ta datum dejansko shranil. imapsync poroča o tem, kar je zahteval, ne o tem, kar je strežnik sprejel.

Ž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 je vrnjeni datum datum migracije namesto 2019-01-15, je ciljni strežnik ignoriral zahtevo imapsync. Dnevnik vam je lagal (no, povedal vam je, kaj je zahteval, ne kaj je dobil).

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 z --syncinternaldates, če ste ga prvič pozabili? Tehnično da, toda imapsync bo preskočil sporočila, ki že obstajajo na cilju (zasnovan je kot idempotenten). Potrebovali bi --delete2 za odstranitev ciljnih sporočil in njihov ponovni prenos, kar je tvegano na produkcijskem nabiralniku. In tudi takrat, če ciljni strežnik ignorira INTERNALDATE, ste nazaj na začetku.

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; težavo s prikazom povzroča obdelava metapodatkov ciljnega strežnika. 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. Popravek obravnava specifične vzorce, ki jih migracije imapsync pustijo za seboj, vključno s karakterističnimi podpisi glav Received od ciljnih strežnikov, ki so prepisali INTERNALDATE.

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 30 dni. Č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