Opravte imapsync dátumy e-mailov

Prísľub --syncinternaldates (a prečo zlyháva)

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 technicky sa o to pokúša. Ale "pokúša sa" nesie v tej vete veľkú záťaž.

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 zachovanie dátumov nie je úplne v rukách imapsync 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 problém: cieľový server nie je povinný tento dátum rešpektovať.

Prečo cieľové servery ignorujú INTERNALDATE

Š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ť." Niekoľko veľkých e-mailových platforiem sa rozhodlo, že majú dobrý dôvod.

Microsoft 365 je najväčší vinník. Keď správa príde cez IMAP APPEND, transportný pipeline Exchange ju opečiatkuje novou hlavičkou Received s aktuálnym dátumom, potom nastaví INTERNALDATE na základe tejto časovej pečiatky doručenia. Nezáleží na tom, aký dátum imapsync požadoval. Server M365 ho prepíše.

Google Workspace (Gmail) sa správa inak, ale stále môže spôsobiť problémy. Implementácia IMAP v Gmaile vo väčšine prípadov rešpektuje INTERNALDATE z APPEND, ale pridá vlastnú hlavičku Received. Ak e-mailový klient čítajúci schránku uprednostňuje hlavičky Received pred INTERNALDATE na zobrazenie (a Outlook to presne robí), dátumy stále vyzerajú nesprávne.

Dovecot a Cyrus, dva najčastejšie open-source IMAP servery, vo všeobecnosti rešpektujú INTERNALDATE z APPEND. Takže migrácie imapsync medzi dvoma Dovecot servermi zvyčajne správne zachovávajú dátumy. Problémy začínajú, keď je cieľom hostovaná platforma s vlastným transportným spracovaním.

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

Aj keď by cieľový server spolupracoval, administrátori často urobia chybu s možnosťami príkazového riadku imapsync. Tu sú chyby, ktoré vidím najčastejšie:

Zabudnutie --syncinternaldates úplne

Príznak nie je predvolene zapnutý. Ak spustíte základný imapsync --host1 zdroj --host2 cieľ --user1 používateľ --user2 používateľ bez neho, imapsync sa vôbec nepokúša zachovať dátumy. Cieľový server použije aktuálnu časovú pečiatku pre každú správu. Toto je najčastejšia príčina a najľahšie sa prehliadne, pretože imapsync vás na to neupozorní.

Použitie --syncinternaldates s --addheader

Niektoré návody odporúčajú použiť --addheader na vloženie vlastnej hlavičky počas migrácie. Ak pridávate hlavičky, modifikujete správu, čo môže spustiť, že cieľový server ju bude považovať za "novú" správu a zodpovedajúco ju opečiatkuje. Interakcia medzi týmito dvoma príznakmi je zle zdokumentovaná.

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.

SSL vyjednávanie spôsobujúce posun časových pečiatok

Pri migrácii cez TLS s --ssl1 a --ssl2 nastavenie pripojenia pridáva latenciu. Pri veľkých migráciách (50 000+ správ) sa táto latencia kumuluje. Hoci nemení dátumy o dni, môže spôsobiť, že správy odoslané v odstupe minút prídu s identickými časovými pečiatkami na cieľ, čím stratia vzájomné poradie.

Čí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ľ. Ale to neznamená, že cieľový server tento dátum skutočne uložil. imapsync hlási to, čo požadoval, nie to, čo server prijal.

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 je vrátený dátum dátumom migrácie namiesto 2019-01-15, cieľový server ignoroval požiadavku imapsync. Log vám klamal (teda, povedal vám, čo požiadal, nie čo dostal).

Táto medzera medzi tým, čo imapsync hlási, a tým, čo sa skutočne deje, je jedným z najfrustrujúcejších aspektov ladenia problémov s dátumami. Môžete pozerať na čistý log súbor hodiny a nikdy si neuvedomíte, že dátumy sú na druhej strane nesprávne.

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 znovu spustiť imapsync s --syncinternaldates, ak ste ho prvýkrát zabudli? 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 aj tak, ak cieľový server ignoruje INTERNALDATE, ste späť na začiatku.

Niektorí administrátori skúšajú hybridný prístup: najskôr spustia imapsync s --dry na test, potom skutočnú migráciu. Ale --dry netestuje, čo cieľový server robí s INTERNALDATE. Iba simuluje prenos. Problém s dátumami je neviditeľný, kým sa správy skutočne nezapíšu na cieľ.

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; problém zobrazenia spôsobuje spracovanie metadát cieľovým serverom. 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. Oprava zvláda špecifické vzory, ktoré migrácie imapsync zanechávajú, vrátane charakteristických podpisov hlavičiek Received od cieľových serverov, ktoré prepísali INTERNALDATE.

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 po dobu 30 dní. 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ť