Opravte imapsync dátumy e-mailov

Prísľub --syncinternaldates (a kde jeho pôsobenie končí)

Spustili ste príkaz imapsync. Zahrnuli ste --syncinternaldates, pretože ste si prečítali dokumentáciu a ste pozorní. Migrácia sa dokončí, log hovorí, že všetko bolo prenesené, nula chýb. Potom otvoríte schránku v Outlooku a každý e-mail zobrazuje včerajší dátum.

Toto je jedna z najčastejších frustrácií s imapsync a mätie systémových administrátorov minimálne od roku 2017. Príznak --syncinternaldates by mal zachovať IMAP INTERNALDATE počas migrácie. A skutočne to robí: každej kópii pridelí interný dátum, ktorý má zdrojový server. Presne tam sa skrýva háčik.

imapsync je open-source nástroj napísaný v Perle Gillesom Lamiralom a je skutočne dobrý v tom, čo robí. Zvláda prenosy IMAP-na-IMAP schránok s úrovňou spoľahlivosti, ktorú väčšina komerčných nástrojov závidí. Ale imapsync môže kopírovať iba dátumy, ktoré nájde, a tu sa veci komplikujú.

Ako IMAP dátumy skutočne fungujú

Existujú tri rôzne "dátumy" zapojené do každého e-mailu a väčšina ľudí (vrátane niektorých IT administrátorov) ich zamieňa:

Hlavička Date: (RFC 2822) - dátum, ktorý e-mailový klient odosielateľa priradil správe pri jej vytvorení. Žije vnútri tela správy a poštové servery ju nikdy nemenia.
Hlavičky Received: - každý poštový server, ktorý spracuje správu, pridá jednu so svojou časovou pečiatkou. Tvoria reťazec od odosielateľa k príjemcovi. Najnovšia hlavička Received je to, čo niektoré e-mailové klienty používajú na zobrazenie.
INTERNALDATE - časová pečiatka na strane IMAP servera, ktorá riadi triedenie správ v schránke. Nastavuje sa pri prvom uložení správy cez IMAP APPEND.

Keď imapsync migruje správu, prečíta ju zo zdrojového servera (vrátane jej INTERNALDATE) a zapíše ju na cieľový server pomocou IMAP APPEND. Príznak --syncinternaldates hovorí imapsync, aby odovzdal zdrojový INTERNALDATE cieľovému serveru počas APPEND.

Tu je dobrá správa: Microsoft 365, Outlook.com a Gmail zachovávajú dátum, ktorý dostanú. Ak sú teda dátumy nesprávne, problém je inde.

Prečo môžu byť dátumy aj tak nesprávne

Špecifikácia IMAP (RFC 3501) hovorí, že ak je dátum-čas poskytnutý s príkazom APPEND, server BY MAL ho použiť. "BY MAL" v jazyku RFC znamená "urobte to, pokiaľ nemáte dobrý dôvod neurobiť." Microsoft 365, Outlook.com a Gmail to skutočne robia: kópia, ktorá si nesie pôvodný dátum, si ho zachová.

imapsync však odovzdáva dátum, ktorý má zdrojový server pre danú správu, nie dátum, kedy bol e-mail odoslaný. V zdravej schránke sa oba dátumy zhodujú. V schránke, ktorá už bola raz migrovaná alebo obnovená zo zálohy, môže zdroj obsahovať dátum tejto skoršej operácie, a imapsync ho jednoducho skopíruje tak, ako je.

Gmail je výnimkou iba vtedy, keď kópia prechádza cez vlastné importné API Gmailu, nie cez IMAP: toto API pridá riadok Received: s dátumom dňa kópie a Outlook môže tento dátum zobraziť. imapsync komunikuje cez IMAP, takže sa ho to netýka.

Dovecot a Cyrus, dva najčastejšie open-source IMAP servery, tiež zachovávajú dátum z APPEND. Takže bez ohľadu na cieľ je otázka rovnaká: aký dátum mal zdroj?

Časté chyby v príkazovom riadku imapsync, ktoré poškodia dátumy

Okrem dátumov zo zdroja sa administrátori často pomýlia v možnostiach príkazového riadku imapsync, alebo obviňujú tie nesprávne. Tu sú chyby, ktoré vidím najčastejšie:

Kopírovanie zo zdroja, ktorého dátumy už boli nesprávne

--syncinternaldates je predvolene zapnutý: imapsync pridelí každej kópii interný dátum, ktorý má zdrojový server (jeho dokumentácia to popisuje ako "Sets the internal dates on host2 as the same as host1"). Ak je zdrojová schránka samotná výsledkom skoršej migrácie alebo obnovenia zo zálohy, jej interné dátumy môžu už byť dátumami tejto operácie, a imapsync tak verne skopíruje nesprávny dátum. Toto je najčastejšia príčina a najľahšie sa prehliadne, pretože log zobrazuje dva identické dátumy.

Použitie --syncinternaldates s --addheader

Niektoré návody odporúčajú použiť --addheader na vloženie vlastnej hlavičky počas migrácie. Pridanie hlavičky správu upraví (o jeden riadok navyše na začiatku), ale nemení dátum, ktorý imapsync odovzdáva, takže nesprávne dátumy tým nevysvetlíte. Kópia jednoducho už nie je identická s pôvodnou správou, čo je dôležité, ak ich porovnávate.

Zamieňanie --minage a --maxage so zachovaním dátumov

Príznaky --minage a --maxage filtrujú, ktoré správy sa majú migrovať na základe veku. Neovplyvňujú spôsob spracovania dátumov na cieli. Videl som administrátorov tráviť hodiny úpravou týchto príznakov v domnení, že opravia problém s dátumami. Neopravia.

Obviňovanie TLS za posunuté dátumy

Cez TLS (--ssl1, --ssl2) nastavenie pripojenia pridáva latenciu a pri veľkej migrácii (50 000+ správ) sa môže spočítať až na hodiny. Dátumov sa to však netýka: každá kópia si nesie dátum, ktorý jej odovzdal imapsync, bez ohľadu na to, kedy skutočne dorazí.

Čítanie logov imapsync: čo výstup skutočne hovorí

imapsync produkuje podrobné logy, čo je výborné. Ale výstup logu môže byť zavádzajúci, pokiaľ ide o dátumy.

Typický riadok úspešného prenosu vyzerá takto:

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

Oba dátumy sa zhodujú. To znamená, že imapsync odoslal správny INTERNALDATE na cieľ. Microsoft 365, Outlook.com a Gmail navyše zachovávajú dátum, ktorý dostanú. Dva identické dátumy však dokazujú len to, že kópia je verná ZDROJU: ak bol zdrojový dátum už nesprávny, obidva stĺpce zobrazujú ten istý nesprávny dátum.

Chcete overiť, čo sa skutočne stalo? Po migrácii sa pripojte k cieľu s IMAP klientom a skontrolujte INTERNALDATE priamo:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Ak vrátený dátum nezodpovedá dátumu, kedy bol e-mail odoslaný, pozrite sa na tú istú správu na zdroji: nájdete tam ten istý nesprávny dátum. Log vám neklamal, iba skopíroval to, čo dostal.

Toto je jeden z najfrustrujúcejších aspektov ladenia problémov s dátumami: čistý log súbor, dva identické dátumy, a napriek tomu nesprávny dátum v Outlooku, pretože chyba tam bola už skôr, než imapsync spustil migráciu.

Veľké migrácie imapsync: kde sa problémy s dátumami znásobujú

Migrácia jednej schránky s imapsync je nepríjemná, keď sa dátumy poškodia. Ale MSP a IT oddelenia spúšťajúce imapsync cez stovky schránok čelia problému úplne iného rozsahu.

Zvážte typický scenár podnikovej migrácie. Presúvate 200 schránok zo servera Zimbra na Microsoft 365. Napíšete obaľovací skript, ktorý prechádza CSV so zoznamom používateľov a volá imapsync pre každého. Migrácia beží cez víkend. V pondelok ráno máte 200 schránok s poškodnenými dátumami a okolo 1,2 milióna e-mailov zobrazujúcich časovú pečiatku migrácie.

Môžete migráciu opraviť opätovným spustením imapsync? Technicky áno, ale imapsync preskočí správy, ktoré už existujú na cieli (je navrhnutý ako idempotentný). Potrebovali by ste --delete2 na odstránenie cieľových správ a ich opätovný prenos, čo je riskantné na produkčnej schránke. A ak bol problém v dátumoch zo zdroja, druhé spustenie skopíruje tie isté nesprávne dátumy znova.

Niektorí administrátori skúšajú hybridný prístup: najskôr spustia imapsync s --dry na test, potom skutočnú migráciu. Ale --dry iba simuluje prenos: zobrazí dátumy, ktoré by imapsync odovzdal, nie to, či sú to dátumy, kedy boli e-maily odoslané. Nič vás neupozorní, že zdrojové dátumy sú už nesprávne.

Vlastné opravy a ich limity

Ak prehľadáte fóra a mailing listy (imapsync-devel zoznam na SourceForge je stále aktívny od začiatku 2026), nájdete návrhy od kreatívnych po nebezpečné.

Niektorí navrhujú použiť Perl jednoradkové riešenie na priamu modifikáciu INTERNALDATE na cieľovom serveri. Iní odporúčajú export všetkých správ do formátu mbox, manipuláciu s dátumami a opätovný import. Niekoľkí napísali Python skripty používajúce imaplib na stiahnutie, modifikáciu a opätovné vloženie správ.

Všetky tieto prístupy zdieľajú rovnaké základné problémy. Ako spracujete S/MIME podpísané správy bez poškodenia podpisu? Čo s viacčasťovými MIME štruktúrami s vnorenými hranicami? Ne-ASCII hlavičkami kódovanými RFC 2047? PGP šifrovanými správami, kde nemôžete ani skontrolovať obsah? Skript, ktorý zvládne 50 testovacích správ vo vývojovom prostredí, sa zasekne na okrajových prípadoch v produkčnej schránke s 30 000 správami.

A najväčšia otázka, ktorú nikto nepoloží, kým nie je neskoro: ako overíte, že každá modifikovaná správa je stále neporušená? Že prílohy sa nepoškodili, že vlákna stále fungujú, že 85 MB tabuľka, ktorú niekto poslal e-mailom v roku 2020, prežila manipuláciu?

Ako Redate.io opravuje problémy s dátumami imapsync

Pôvodná hlavička Date: je po migrácii imapsync vždy neporušená. imapsync verne prenáša surovú správu; nesprávny dátum sa nachádza v metadátach, ktoré kópia dostala, nie v samotnej správe. Táto pôvodná hlavička umožňuje opravu.

Redate.io sa priamo pripája k schránke (Google Workspace, Microsoft 365 alebo akýkoľvek IMAP server), skenuje e-maily s anomáliami dátumov a aplikuje cielenú opravu metadát cez proprietárny pipeline analýzy reťazca hlavičiek a rekonštrukcie dátumov. Nemusí vedieť, aký nástroj migráciu vykonal: nájde e-maily, ktorých zobrazený dátum nezodpovedá ich pôvodnému dátumu.

Každý opravený e-mail sa overuje individuálne: integrita správy, zachovanie príloh, umiestnenie v priečinku, vlákna, štítky. Originály sa uchovávajú v viditeľnom záložnom priečinku Redate.io - Originals dokým ich sami neodstránite. Ak niečo vyzerá nesprávne, vrátenie je na jeden klik.

Bezplatné skenovanie sa pripojí k schránke, identifikuje každý e-mail s anomáliou dátumu a nahlási presný počet a cenu. Bez kreditnej karty, bez inštalácie softvéru. Pre špecifiká vašej platformy:

Redate.io funguje aj na migráciách, ktoré sa uskutočnili pred mesiacmi alebo rokmi. Hlavička Date: nestráca platnosť a ani schopnosť opraviť to, čo sa pokazilo.

Migrovali ste s imapsync a zostali s nesprávnymi dátumami? Spustite bezplatné skenovanie a zistite presne, koľko e-mailov je postihnutých.

imapsync nezachoval dátumy? Ako ich opraviť