Outlook: datum migrace IMAP vs datum odeslání

Příznak, který každý zná

Právě jste dokončili migraci IMAP do Microsoft 365 nebo Google Workspace. V pondělí ráno začínají přicházet tickety: "Všechny e-maily mají stejné datum", "Moje historie je rozbitá", "V schránce už nic nenajdu". Otevřete Outlook a skutečně, tisíce e-mailů zobrazují datum z minulého víkendu. Ne datum, kdy byly odeslány. Datum, kdy proběhla migrace.

To není chyba Outlooku. Je to přímý důsledek fungování protokolu IMAP a migračních nástrojů. Ale abyste pochopili proč, musíte otevřít kapotu.

Tři data v jednom e-mailu

E-mail je složitější, než se zdá. Hlavičky, tělo zprávy, přílohy... a několik odlišných časových razítek, která koexistují vedle sebe. (Mimochodem, pokud jste někdy zkusili číst surové hlavičky e-mailu, víte, že to není zrovna odpočinková četba.)

Hlavička Date: (RFC 2822)

To je datum, které odesílatel vložil do zprávy v okamžiku odeslání. Definované standardem RFC 2822, vypadá takto:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Tato hlavička je pevně zabudovaná do obsahu zprávy. Nikdy se nemění, pokud někdo nepozměnil surový obsah e-mailu. To je "datum odeslání" v pravém slova smyslu.

Hlavička Received: (přidávána na každém síťovém uzlu)

Každý server, který se e-mailu dotkne při přenosu, přidá na začátek zprávy hlavičku Received: s vlastním datem. E-mail, který projde třemi servery, tedy nasbírá tři hlavičky Received:. Nejnovější je vždy první. Výsledek vypadá přibližně takto:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Když migrační nástroj jako BitTitan MigrationWiz, CloudM, imapsync nebo GSMMO přesune e-mail ze zdrojového serveru na cílový, chová se také jako "síťový uzel". Vloží novou hlavičku Received: na samý vrchol zásobníku, s datem a časem migrace.

IMAP INTERNALDATE

To je třetí datum, a to je to problematické. INTERNALDATE je metadata uložená na straně IMAP serveru, nezávislá na obsahu zprávy. Představuje datum, kdy byl e-mail doručen (nebo vložen) do poštovní schránky. Když migrační nástroj vloží e-mail, sám rozhoduje, jakou hodnotu INTERNALDATE nastaví. A v mnoha případech nástroje použijí datum okamžiku migrace. Ne původní datum.

Tam se to celé zasekne.

Proč Outlook zobrazuje datum migrace

Outlook používá INTERNALDATE pro zobrazení sloupce "Přijato". To je jeho výchozí chování, konzistentní se specifikací IMAP: INTERNALDATE má reprezentovat datum přijetí do schránky. V normálním průběhu (skutečný příchozí e-mail) je INTERNALDATE blízká datu v hlavičce Date:. Obě hodnoty jsou konzistentní.

Po neúspěšné migraci ukazuje INTERNALDATE všech importovaných e-mailů na noc ze 14. na 15. června 2024 (nebo na jakékoli jiné datum migrace). Outlook tuto hodnotu přečte, zobrazí ve sloupci "Přijato", a výsledek je katastrofální: 45 000 e-mailů jakoby dorazilo během jediného večera.

Upřesním: první hlavička Received: (nejnovější v zásobníku) také ovlivňuje zobrazení v některých konfiguracích. Ale INTERNALDATE zůstává hlavním faktorem pro sloupec "Přijato" v Outlooku v synchronizovaném IMAP režimu.

Řešení "Přidat sloupec Odesláno" v Outlooku

První věc, kterou většina IT administrátorů po objevení problému udělá, je hledat obejití na straně klienta. A jedno skutečně existuje.

V Outlooku lze upravit zobrazení sloupců složky a nahradit (nebo doplnit) sloupec "Přijato" sloupcem "Datum" nebo "Odesláno". Sloupec "Datum" čte přímo hlavičku Date: zprávy, nikoli INTERNALDATE. Protože hlavička Date: nebyla migrací dotčena, původní data se znovu zobrazí.

Postup v Outlooku (desktopová verze, Microsoft 365): klikněte pravým tlačítkem na záhlaví sloupce v seznamu zpráv, "Nastavení zobrazení", pak upravte sloupce, odeberte "Přijato" a přidejte "Datum". Lze nasadit přes GPO pro hromadné nasazení.

Dobře. Na papíře to vizuální problém řeší. V praxi je to náplast na tepnu.

Konkrétní limity tohoto řešení

Mobilní a webové klienty

Outlook na iOS, Androidu a Outlook Web App (OWA) nemají stejné možnosti přizpůsobení. Úprava zobrazení, kterou jste nasadili na Windows počítačích, se nepřenese. Uživatelé, kteří čtou e-maily na telefonu, nadále vidí datum migrace. A ve středně velké firmě je to pravděpodobně polovina uživatelů.

Vyhledávání

Vyhledávání Outlooku používá index Windows Search (nebo index Exchange/Microsoft 365 na straně serveru). Tento index je sestavován z INTERNALDATE, nikoli z hlavičky Date:. Když uživatel hledá "e-maily z ledna 2022", vyhledávání vrátí e-maily, jejichž INTERNALDATE je v lednu 2022. Ne ty, jejichž hlavička Date: je v lednu 2022. Výsledek: staré e-maily se v datových filtrech vůbec neobjeví. Změna zobrazovacího sloupce na tom nic nemění.

Pravidla zpráv

Pravidla Outlooku ("pokud byl e-mail přijat před..." nebo "pokud byl e-mail přijat po...") také používají INTERNALDATE. Pravidlo třídění nebo archivace na základě časových rozsahů nebude po migraci fungovat správně, pokud INTERNALDATE nebyla opravena.

Shoda a eDiscovery

To je možná nejzávažnější bod. Nástroje pro zajištění shody, právní archivaci a eDiscovery (například Microsoft Purview) používají INTERNALDATE jako referenční datum pro právní dotazy. Pokud vaše firma podléhá povinnostem uchovávání dat nebo musí odpovídat na požadavky v rámci discovery, poškozené INTERNALDATE mohou způsobit skutečné právní problémy. Audit žádající "všechny e-maily mezi tímto a tímto datem" nevrátí správné výsledky.

Nástroje třetích stran

CRM systémy, ticketovací nástroje, archiváře... vše, co se připojuje k vašemu poštovnímu serveru přes IMAP nebo API Microsoft 365/Google Workspace, čte INTERNALDATE. Změna zobrazení v Outlooku pro tyto systémy nic neopraví.

Jediné skutečné řešení: oprava na úrovni serveru

Řazení podle data odeslání v Outlooku není řešení. Je to náplast. Skutečná oprava musí proběhnout na úrovni metadat serveru, nikoli v klientském zobrazení.

Konkrétně to znamená opravit INTERNALDATE každého e-mailu tak, aby odpovídala původnímu datu z hlavičky Date:. Původní hlavička Date: je v zprávě stále přítomna (migrace ji nevymazala), což opravu umožňuje. Tam se nachází skutečná informace o datu.

Na Google Workspace API Gmailu zpřístupňuje parametr internalDate, který umožňuje přímo pracovat s tímto metadatem. Na Microsoft 365 je mechanismus odlišný, ale očekávaný výsledek je stejný. Na standardním IMAP serveru standard počítá s tím, že datum lze zadat při vkládání zprávy.

V praxi provést tuto operaci na desítkách tisíc e-mailů v produkčním prostředí, bez ztráty dat, bez duplikátů, bez rozbití vláken diskuze nebo štítků, se zvládnutím okrajových případů (S/MIME podepsané zprávy, složité MIME struktury, non-ASCII kódování podle RFC 2047, objemné přílohy)... to je jiná kategorie. Skript, který funguje na 50 testovacích e-mailech, neobstojí na schránce se 40 000 zprávami. Zvládání chyb 429 (překročení kvóty API), síťových timeoutů ve 2 hodiny v noci, zpráv s MIME strukturou částečně poškozenou ještě při migraci... to vše vyžaduje solidní technické řemeslo.

Přesně to dělá Redate.io. Proprietární opravný engine analyzuje řetězec hlaviček každého e-mailu, identifikuje spolehlivé původní datum a provede cílenou opravu metadat bez zásahu do obsahu zprávy. Každý opravený e-mail je ověřen individuálně. Originály jsou uchovány v záložní složce po dobu 30 dní, což zajišťuje možnost vrácení zpět kdykoli. Něco, co domácí skript nikdy nenabídne.

Identifikace odpovědného migračního nástroje

Problém se projevuje stejně bez ohledu na původ migrace, ale detaily se liší podle použitého nástroje. BitTitan MigrationWiz, CloudM, imapsync a GSMMO mají každý svůj otisk v hlavičkách Received:, které vkládají. Analytický pipeline Redate.io udržuje databázi shod pro stovky signatur známých migračních nástrojů, aby odlišil migrační hlavičku od zbytku legitimního přenosového řetězce.

Pokud nevíte, který nástroj byl pro vaši migraci použit (to se stane, zejména když přebíráte správu po jiném MSP), bezplatný scan Redate.io identifikuje dotčené schránky a odhadne objem k opravě ještě před jakýmkoli závazkem.

Pro konkrétní situace jsou k dispozici podrobné průvodce: oprava dat imapsync v Outlooku, oprava dat BitTitan v Outlooku nebo oprava dat CloudM v Outlooku.

Co udělat nyní

Pokud čtete tento článek po migraci, dobrá zpráva je, že původní hlavička Date: je v každém z vašich e-mailů nedotčena. Informace o skutečném datu jsou tam, přítomné v každé zprávě. Problém je v metadatech, ne v obsahu. A metadata se opravit dají.

Můžete si také přečíst článek IMAP INTERNALDATE: proč se datumy pokazí pro hlubší pochopení mechaniky problému, nebo kompletního průvodce chybnými daty v Outlooku po migraci, pokud chcete přehled různých scénářů.

Připraveni opravit data ve svých poštovních schránkách? Spusťte bezplatný scan na Redate.io a identifikujte dotčené e-maily a odhadněte objem ještě před jakoukoli opravou.