Špatné datum e-mailů po migraci do Exchange Online

Klasický scénář pondělního rána

Právě jste dokončili migraci IMAP do Exchange Online. Batch proběhl bez chyb v centru správy Exchange, schránky jsou synchronizované, uživatelé se mohou přihlásit. V pátek večer zavíráte notebook s pocitem dobře odvedené práce.

V pondělí ráno začnou chodit tickety. "Všechny moje e-maily mají datum pátku." "Historii doručené pošty nemůžu použít." "Chybí mi staré zprávy." Ve skutečnosti nic nechybí: e-maily jsou tam, ale Outlook je zobrazuje s datem migrace místo původního data odeslání. E-mail z roku 2019 vypadá, jako by přišel minulý pátek. Výsledek: celá schránka zdánlivě obsahuje jen nedávné zprávy.

Jde o jeden z nejfrustru­jících problémů migrace IMAP do Exchange Online, a Microsoft ho ve své dokumentaci téměř systematicky přehlíží.

Proč migrace přes EAC kazí data

Když použijete centrum správy Exchange (EAC) k nastavení migrace IMAP ze zdrojového serveru (Dovecot, Courier, Cyrus, UW-IMAP, nezáleží na tom), Exchange Online se připojí k vašemu zdrojovému serveru přes IMAP, načte zprávy a vloží je do cílových schránek vlastním interním transportním kanálem.

Právě tady vzniká problém.

Každý e-mail, který prochází transportním kanálem Exchange, automaticky dostane opatřenou hlavičku Received: s časovým razítkem. Jde o standardní chování SMTP a IMAP serverů po celá desetiletí: každý server, který se zprávy dotkne, přidá své časové razítko. Problém je, že Outlook (zejména Outlook pro Windows v novějších verzích) používá nejnovější hlavičku Received: jako referenci pro zobrazení, pokud jsou ostatní metadata nejednoznačná.

Původní hlavička Date: (ta, která říká, kdy byl e-mail skutečně odeslán ve smyslu RFC 2822) je ve zprávě stále přítomna. Nebyla odstraněna. Ale je "zastíněna" tou novou hlavičkou Received:, kterou Exchange přidal při vkládání.

Zároveň se IMAP INTERNALDATE (metadata, které IMAP servery používají k vnitřnímu datování zpráv a které řídí řazení ve většině klientů) nastaví na datum vložení, nikoli na původní datum e-mailu. Exchange Online nemá nativní způsob, jak zachovat INTERNALDATE zdrojového serveru během dávkové migrace přes EAC.

EAC vs. nástroje třetích stran: důležitý rozdíl

Tady je třeba rozlišit dvě situace. U nástrojů jako BitTitan MigrationWiz nebo CloudM Migrate existuje stejný problém, ale tyto nástroje někdy obsahují konfigurační možnosti (částečně zdokumentované, často skryté v pokročilých nastaveních), které se snaží zachovat některá metadata týkající se data zprávy.

Nativní migrace přes EAC nic podobného nenabízí. Microsoft nezpřístupňuje žádný parametr pro řízení zachování INTERNALDATE v dávkové migraci. Je to černá skřínka: nastavíte dávku, spustíte ji a Exchange uvnitř dělá, co chce. A to, co dělá, je vždy stejné: zprávám přiřadí datum podle okamžiku vložení.

(Pokud jste se někdy pokusili přečíst si syrové hlavičky e-mailu migrovaného přes EAC, víte, že hlavička Received: přidaná Exchange je na první pohled rozpoznatelná: obsahuje odkazy na interní servery Microsoftu jako *.protection.outlook.com nebo *.prod.exchangelabs.com, s časovým razítkem, které přesně odpovídá vašemu migračnímu oknu.)

Proč opětovné vytvoření dávky nic neopraví

Instinktivní reakce mnoha IT administrátorů zní: "Když migrované schránky odstraním a dávku spustím znovu od začátku, možná budou datumy tentokrát správné."

Je to pochopitelné. Ale nefunguje to.

Problém není v konfiguraci dávky. Nejde o zaškrtávací pole, které jste přehlédli. Je v samotné architektuře transportního kanálu Exchange, který se chová stejně při každé migraci. Opětovné spuštění dávky produkuje přesně stejný výsledek: stejné hlavičky Received: s novým datem migrace a stejné nesprávné hodnoty INTERNALDATE. Ztratíte čas a podruhé zbytečně narušíte uživatele.

Někteří administrátoři také zkoušejí upravit nastavení řazení v Outlooku ("řadit podle data odeslání" místo "podle data přijetí"). Řazení podle data odeslání není oprava. Je to náplast. Hlavička Date: a INTERNALDATE zůstávají nesprávné pro klienty, kteří toto nastavení nenabízejí, pro OWA, pro Outlook Mobile a pro jakoukoli aplikaci třetí strany, která ke schránce přistupuje přes IMAP nebo EWS.

Co se skutečně děje v hlavičkách

Zde je zjednodušený příklad, jak vypadá e-mail po migraci přes EAC. Původní hlavička:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@olddomain.com
Subject: Q1 2019 Report

Po migraci se do řetězce hlaviček zprávy vloží něco jako toto:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook uvidí tuto hlavičku Received: jako první (je přidána na začátek bloku hlaviček), interpretuje ji jako nejnovější datum zpracování a zobrazí ji jako datum přijetí. Původní hlavička Date: z roku 2019 je stále přítomna, nezměněná, o pár řádků níž. Ale Outlook ji nepoužívá pro zobrazení v seznamu zpráv.

Přesněji: chování se mírně liší podle verze Outlooku. Verze po roce 2021 (a zejména nový Outlook pro Windows zaváděný od konce roku 2023) na to reagují citlivěji, protože se spoléhají více na metadata Exchange Graph než na samotnou hlavičku Date:. To znamená, že migrace, které s Outlookem 2016 nezpůsobily žádný viditelný problém, se nyní mohou rozbít s novým Outlookem.

Kdo je skutečně zasažen

Nejčastějšími zdrojovými servery IMAP u tohoto typu migrace jsou Dovecot (rozšířený v prostředích Linux/cPanel) a Courier. Oba přes IMAP zpřístupňují hodnoty INTERNALDATE, které EAC nezachovává. Pokud migrujete z lokálního Exchange do Exchange Online (hybridní nebo cutover migrace), chování je jiné, protože Microsoft používá interní transportní protokol (MAPI/EWS), který metadata zachovává lépe. Problém způsobuje obecná migrace IMAP přes EAC.

Nejvíce postiženi jsou uživatelé s dlouhou historií schránky (5 a více let) a vysokým objemem zpráv. Uživatel s 300 e-maily se rychle zorientuje. Obchodní ředitel s 12 000 e-maily řazenými podle data, na které denně spoléhá při vyhledávání vláken s klienty, je fakticky paralyzován.

Proč je vlastní skript špatný nápad

Někteří IT administrátoři, kteří technický problém chápou, jsou v pokušení napsat skript v PowerShellu nebo Pythonu, který hlavičky opraví ručně. Základní princip může působit jednoduše, jakmile mechanismus odhalíte. Ale skutečně provést opravu v produkčním prostředí je úplně jiná věc.

Nejprve okrajové případy. E-maily podepsané S/MIME a zprávy šifrované PGP mají strukturu, která nesnese úpravu hlaviček bez zneplatnění podpisu. Zprávy multipart/alternative s poškozenými hranicemi MIME (běžné na starších serverech Courier) může skript, který zprávu upraví bez správné rekonstrukce struktury, poškodit. Hlavičky v jiném než ASCII kódování podle RFC 2047 (například jména odesílatelů s diakritikou nebo v japonštině) jsou klasickým zdrojem chyb.

Pak je tu objem. Skript, který funguje na 50 testovacích e-mailech ve vývojovém prostředí, si neporadí s limity Exchange Online API v produkci. Chyba 429 Too Many Requests ve 2 hodiny ráno během dávky 8 000 zpráv, bez mechanismu opakování, znamená bezesnou noc a potenciálně zdvojené nebo ztracené zprávy.

A ta větší otázka: jak ověříte, že je každý opravený e-mail neporušený? Že žádná příloha není zkrácená, žádné vlákno rozbité, že štítky a složky zůstaly zachovány? Bez individuální kontroly jen doufáte, že vše proběhlo v pořádku.

Opravit datum e-mailů po migraci je problém, který vypadá jako skript na 50 řádků, ale pro spolehlivost v produkci potřebuje tisíce řádků.

Co Redate.io dělá jinak

Každý uživatel se přihlásí svým vlastním účtem Microsoft a Redate.io otevře tuto jednu schránku, aby zkontrolovalo e-maily, jejichž datum bylo migrací změněno. Tato kontrola je zdarma a dává přesný obraz rozsahu problému: počet postižených zpráv, které schránky, rozsah změněných datumů.

Vlastní opravný nástroj Redate.io pak zpracuje každý e-mail jednotlivě: rozpozná e-maily, jejichž zobrazené datum neodpovídá jejich původnímu datu, bez ohledu na to, jaký nástroj migraci provedl, a před opravou i po ní provede ověření struktury a shody s RFC. E-maily podepsané S/MIME, složité struktury MIME, nestandardní kódování: vše má vlastní zpracování.

Každá opravená zpráva je ověřena jednotlivě. Originály zůstávají viditelné ve složce zálohy uvnitř vaší vlastní schránky, dokud je sami neodstraníte. Pokud se u konkrétní zprávy něco jeví podezřele, zůstane nedotčena: Redate.io anomálii oznámí, raději než by riskovalo poškození.

Redate.io opravuje datum e-mailů bez zásahu do jejich obsahu, příloh nebo umístění ve složkách.

Pro migrace do Exchange Online konkrétně se každý uživatel přihlásí svým vlastním účtem Microsoft, a pokud organizace vyžaduje schválení administrátorem, Redate.io připraví odkaz, který lze administrátorovi přeposlat, což usnadňuje zpracování většího množství schránek IT administrátorovi nebo poskytovateli IT služeb.

Pokud správujete více klientů, kteří prošli tímto typem migrace, podívejte se také na úplného průvodce opravou datumu e-mailů po migraci Microsoft 365 pro přehled různých scénářů, které pokrývá.

E-maily tam jsou, a stejně tak původní datumy. Spusťte bezplatnou kontrolu na Redate.io a zjistěte přesně, kolik zpráv je ve vašich schránkách Exchange Online zasaženo, než se rozhodnete, co dál.