Opravit datum e-mailů po imapsync

Slib --syncinternaldates (a kde končí)

Spustili jste příkaz imapsync. Přidali jste --syncinternaldates, protože jste si přečetli dokumentaci a jste pečliví. Migrace skončila, log říká, že se přeneslo všechno, nula chyb. Pak otevřete schránku v Outlooku a každý e-mail ukazuje včerejší datum.

Toto je jedna z nejčastějších frustrací s imapsync, a mate správce systémů minimálně od roku 2017. Příznak --syncinternaldates má zachovat IMAP INTERNALDATE během migrace. A daří se mu to: dá každé kopii interní datum, které zdrojový server uchovává. A přesně tady je ta záludnost.

imapsync je open-source nástroj v Perlu, napsaný Gillesem Lamiralem, a je opravdu dobrý v tom, co dělá. Zvládá přenosy schránek IMAP-to-IMAP se spolehlivostí, kterou mu závidí řada komerčních nástrojů. Ale imapsync může zkopírovat jen ty datumy, které najde, a tam se věci komplikují.

Jak data v IMAP skutečně fungují

V každém e-mailu existují tři různá "data" a většina lidí (včetně některých IT správců) je zaměňuje:

Hlavička Date: (RFC 2822) - datum, které e-mailový klient odesílatele vložil do zprávy při jejím vytvoření. Toto datum žije v těle zprávy a poštovní servery je nikdy nemění.
Hlavičky Received: - každý poštovní server, který zprávu zpracuje, přidá jednu se svým vlastním časovým razítkem. Tvoří řetězec od odesílatele k příjemci. Nejvyšší (nejnovější) hlavička Received je ta, kterou někteří e-mailoví klienti používají pro zobrazení.
INTERNALDATE - časové razítko na straně serveru IMAP, které určuje pořadí zpráv ve schránce. Nastavuje se při prvním uložení zprávy pomocí IMAP APPEND.

Když imapsync migruje zprávu, přečte ji ze zdrojového serveru (včetně jejího INTERNALDATE) a zapíše ji na cílový server pomocí IMAP APPEND. Příznak --syncinternaldates říká imapsync, aby při APPEND předal zdrojové INTERNALDATE cílovému serveru.

Tady je dobrá zpráva: Microsoft 365, Outlook.com a Gmail zachovají datum, které jim je předáno. Když jsou tedy data nesprávná, problém je jinde.

Proč mohou být data přesto špatně

IMAP specifikace (RFC 3501) říká, že pokud je s příkazem APPEND poskytnuto datum a čas, server by je MĚL použít. "SHOULD" v jazyce RFC znamená "udělejte to, pokud k tomu nemáte dobrý důvod". Microsoft 365, Outlook.com a Gmail to dělají: kopie, která nese své původní datum, si je zachová.

To, co imapsync předává, je ale datum, které ZDROJOVÝ server pro danou zprávu uchovává, ne datum, kdy byl e-mail odeslán. U zdravé schránky se obě data shodují. U schránky, která už jednou byla migrována nebo obnovena ze zálohy, může zdroj uchovávat datum té dřívější operace, a imapsync ho zkopíruje tak, jak je.

Gmail je zvláštní případ jen tehdy, když kopie proběhne přes vlastní importní API Gmailu místo IMAP: toto API přidá řádek Received: s datem dne kopie, a Outlook toto datum může zobrazit. imapsync mluví IMAP, takže se ho to nedotýká.

Dovecot a Cyrus, dva nejběžnější open-source servery IMAP, také zachovávají datum z APPEND. Ať je tedy cíl jakýkoli, otázka zůstává stejná: jaké datum uchovával zdroj?

Časté chyby v příkazovém řádku imapsync, které rozbíjejí data

Kromě zdrojových dat správci často naráží na možnosti příkazového řádku imapsync, nebo obviňují ty nesprávné. Zde jsou chyby, které vídám nejčastěji:

Kopírování ze zdroje, jehož data už byla špatně

--syncinternaldates je ve výchozím nastavení zapnutý: imapsync dá každé kopii interní datum, které zdrojový server uchovává (podle jeho dokumentace: "Sets the internal dates on host2 as the same as host1"). Pokud je zdrojová schránka sama výsledkem dřívější migrace nebo obnovy ze zálohy, její interní data mohou už odpovídat této operaci, a imapsync věrně zkopíruje špatné datum. Toto je nejčastější příčina, a nejsnáze se přehlédne, protože log ukazuje dvě shodná data.

Použití --syncinternaldates s --addheader

Některé návody doporučují použít --addheader k vložení vlastní hlavičky během migrace. Přidání hlavičky zprávu upraví (o jeden řádek navrch), ale nemění datum, které imapsync předává, takže to nevysvětlí špatná data. Kopie prostě už není totožná s originálem, což je důležité, pokud oba porovnáváte.

Záměna --minage a --maxage se zachováním data

Příznaky --minage a --maxage filtrují, které zprávy se mají migrovat, podle jejich stáří. Neovlivňují, jak se s daty zachází na cíli. Viděl jsem správce, kteří strávili hodiny laděním těchto příznaků v přesvědčení, že tím opraví problém s daty. Neopraví.

Obviňování TLS z posunutých dat

Přes TLS (--ssl1, --ssl2) navazování spojení přidává latenci, a u rozsáhlé migrace (50 000+ zpráv) se to sečte na hodiny. Datumů se to ale nedotkne: každá kopie nese datum, které imapsync předá, ať už reálně dorazí v jakoukoli hodinu.

Čtení logů imapsync: co výstup skutečně říká

imapsync produkuje podrobné logy, což je výborné. Ale výstup logu může být u dat zavádějící.

Typický řádek úspěšného přenosu vypadá takto:

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

Obě data se shodují. To znamená, že imapsync odeslal cílovému serveru správné INTERNALDATE. A Microsoft 365, Outlook.com a Gmail všechny zachovají datum, které jim je předáno. Ale dvě shodná data dokazují jen to, že kopie je věrná ZDROJI: pokud bylo zdrojové datum už špatně, oba sloupce zobrazí stejné špatné datum.

Chcete ověřit, co se skutečně stalo? Po migraci se připojte k cíli e-mailovým klientem IMAP a zkontrolujte INTERNALDATE přímo:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Pokud vrácené datum není datum, kdy byl e-mail odeslán, podívejte se na stejnou zprávu na zdroji: najdete tam stejné špatné datum. Log nelhal, zkopíroval to, co dostal.

Toto je jeden z nejfrustrujících aspektů řešení problémů s daty: čistý log, dvě shodná data, a přesto špatné datum v Outlooku, protože chyba tam byla ještě před tím, než imapsync běžel.

Rozsáhlé migrace imapsync: kde se problémy s daty násobí

Migrace jedné schránky pomocí imapsync je nepříjemná, když se data rozbijí. Ale poskytovatelé IT služeb a IT oddělení, kteří provozují imapsync napříč stovkami schránek, čelí problému úplně jiného rozsahu.

Uvažujme typický scénář podnikové migrace. Přesouváte 200 schránek ze serveru Zimbra do Microsoft 365. Napíšete obalový skript, který projde CSV se seznamem uživatelů a pro každého z nich zavolá imapsync. Migrace běží celý víkend. V pondělí ráno máte 200 schránek se špatnými daty a kolem 1,2 milionu e-mailů celkem, které ukazují časové razítko migrace.

Můžete imapsync pustit znovu a opravit to? Technicky ano, ale imapsync přeskočí zprávy, které na cíli už existují (je navržený, aby byl idempotentní). Potřebovali byste --delete2 k odstranění cílových zpráv a jejich opětovnému přenosu, což je u produkční schránky riskantní. A pokud problémem byla zdrojová data, druhý běh zkopíruje stejná špatná data znovu.

Někteří správci zkoušejí hybridní přístup: nejprve spustit imapsync s --dry pro test, pak skutečnou migraci. Ale --dry jen simuluje přenos: ukáže datumy, které by imapsync předal, ne to, zda jde o datumy, kdy byly e-maily odeslány. Nic Vás neupozorní, že zdrojová data jsou už špatně.

Vlastní opravy a jejich limity

Pokud budete hledat na fórech a v mailing listech (seznam imapsync-devel na SourceForge je stále aktivní i začátkem roku 2026), najdete návrhy od tvořivých až po nebezpečné.

Někteří lidé doporučují použít jednořádkový skript v Perlu k úpravě INTERNALDATE přímo na cílovém serveru. Jiní doporučují exportovat všechny zprávy do formátu mbox, upravit data a znovu je naimportovat. Několik lidí napsalo skripty v Pythonu, které pomocí imaplib stahují, upravují a znovu vkládají zprávy.

Všechny tyto přístupy sdílejí stejné základní problémy. Jak zpracujete zprávy podepsané S/MIME, aniž byste rozbili podpis? Co vícedílné struktury MIME s vnořenými hranicemi? Ne-ASCII hlavičky kódované podle RFC 2047? Zprávy zašifrované PGP, jejichž obsah nelze ani prohlédnout? Skript, který zvládne 50 testovacích zpráv ve vývojovém prostředí, se zadrhne na okrajových případech v produkční schránce s 30 000 zprávami.

A ta největší otázka, kterou si nikdo nepoloží, dokud není pozdě: jak ověříte, že je každá jedna upravená zpráva stále v pořádku? Že se nepoškodily přílohy, že vlákna stále fungují, že tabulka o 85 MB, kterou někdo poslal e-mailem v roce 2020, tu úpravu přežila?

(Pokud jste někdy zkoušeli parsovat surové hlavičky e-mailů v Perlu, víte, že to zrovna není odpočinková aktivita na odpoledne.)

Jak Redate.io opravuje data po imapsync

Původní hlavička Date: je po migraci imapsync vždy nedotčená. imapsync přenáší surovou zprávu věrně; špatné datum sídlí v metadatech, která kopie obdržela, ne ve zprávě. Právě tato původní hlavička umožňuje opravu.

Redate.io se připojí přímo ke schránce (Google Workspace, Microsoft 365 nebo jakýkoli server IMAP), zkontroluje e-maily s anomáliemi v datu a použije cílenou opravu metadat pomocí vlastního postupu analýzy řetězce hlaviček a rekonstrukce data. Nemusí vědět, jaký nástroj migraci provedl: najde e-maily, jejichž zobrazené datum neodpovídá jejich původnímu datu.

Každý opravený e-mail se ověří jednotlivě: integrita zprávy, zachování příloh, umístění ve složce, vlákna, štítky. Originály se uchovávají ve viditelné záložní složce Redate.io - Originals a zůstávají tam, dokud je sami neodstraníte. Pokud něco nevypadá správně, vrácení zpět je na jedno kliknutí.

Bezplatná kontrola se připojí ke schránce, identifikuje každý e-mail s anomálií v datu a zobrazí přesný počet a cenu. Není potřeba platební karta, není potřeba instalovat žádný software. Pro podrobnosti k Vaší platformě:

Redate.io funguje i na migracích, které proběhly před měsíci nebo lety. Hlavička Date: nevyprší, a stejně tak nevyprší ani možnost opravit, co se pokazilo.

Migrovali jste pomocí imapsync a e-mailům zůstalo špatné datum? Spusťte bezplatnou kontrolu a zjistěte, kolika e-mailů se to týká.

imapsync: data se nezachovala? Jak je opravit