Nesprávne dátumy emailov po migrácii na Exchange Online

Klasický scenár pondelkového rána

Práve ste dokončili migráciu IMAP na Exchange Online. Batch prebehol bez chyby v centre spravovania Exchange, schránky sú synchronizované, používatelia sa môžu prihlásiť. V piatok večer zatvárate počítač s pocitom dobre vykonanej práce.

Pondelok ráno začínajú prichádzať tikety. "Všetky moje emaily sú datované piatkum." "Môj archív doručenej pošty je nepoužiteľný." "Chýbajú staré emaily." V skutočnosti nič nechýba: emaily sú tam, ale Outlook ich zobrazuje s dátumom migrácie namiesto pôvodného dátumu odoslania. Email z roku 2019 sa zobrazuje s dátumom minulého piatka. Výsledok: celá schránka vyzerá, akoby obsahovala len nedávne správy.

Ide o jeden z najfrustrujúcejších problémov migrácií IMAP na Exchange Online, ktorý Microsoft takmer systematicky poddokumentuje.

Prečo migrácia cez EAC kazí dátumy

Keď používate centrum spravovania Exchange (EAC) na konfiguráciu migrácie IMAP z lokálneho servera (Dovecot, Courier, Cyrus, UW-IMAP, nech je to čokoľvek), Exchange Online sa pripojí k zdrojovému serveru cez IMAP, stiahne správy a vloží ich do cieľových schránok cez vlastný interný transportný pipeline.

Tu sa problém vytvára.

Každý email prechádzajúci cez transportný pipeline Exchange automaticky dostane hlavičku Received: s časovou pečiatkou. Je to štandardné správanie SMTP a IMAP serverov po desaťročia: každý server, ktorý sa dotkne správy, pridá svoju časovú signatúru. Problém je, že Outlook (a obzvlášť Outlook pre Windows v novších verziách) používa najnovšiu hlavičku Received: ako referenčnú hodnotu pre zobrazenie, keď sú ostatné metadáta nejednoznačné.

Pôvodná hlavička Date: (tá, ktorá uvádza, kedy bol email skutočne odoslaný v zmysle RFC 2822) je stále prítomná v správe. Nebola odstránená. Ale "zatieni" ju nová hlavička Received: pridaná Exchangom pri vkladaní správy.

Zároveň IMAP INTERNALDATE (metadáta, ktoré IMAP servery používajú na interné datovanie správ a ktoré riadia triedenie vo väčšine klientov) je nastavená na dátum vloženia, nie na pôvodný dátum emailu. Exchange Online nemá žiadny natívny spôsob, ako zachovať INTERNALDATE zo zdrojového servera pri hromadnej migrácii cez EAC.

EAC vs. nástroje tretích strán: dôležitý rozdiel

Treba rozlišovať dve situácie. Pri nástrojoch ako BitTitan MigrationWiz alebo CloudM Migrate problém tiež existuje, ale tieto nástroje majú niekedy konfiguračné možnosti (čiastočne zdokumentované, často ukryté v pokročilých nastaveniach), ktoré sa pokúšajú zachovať niektoré metadáta dátumov.

Natívna migrácia cez EAC takúto možnosť neponúka vôbec. Microsoft nevystavuje žiadny parameter na riadenie zachovania INTERNALDATE v pipeline hromadnej migrácie. Je to čierna skrinka: nakonfigurujete batch, spustíte ho, Exchange robí interne čo chce. A to, čo robí systematicky, je datovanie správ podľa dátumu ich vloženia.

(Mimochodom, ak ste niekedy skúšali čítať surové hlavičky emailu migrovaného cez EAC, viete, že hlavička Received: pridaná Exchangom je dobre rozpoznateľná: obsahuje referencie na interné servery Microsoftu ako *.protection.outlook.com alebo *.prod.exchangelabs.com, s časovou pečiatkou, ktorá presne zodpovedá oknu migrácie.)

Prečo znovu vytvorenie batchu nič nerieši

Inštinktívna reakcia mnohých IT adminov na tento problém je: "Ak vymaažem migrované schránky a spustím batch odznova, možno tentoraz budú dátumy správne."

Je to pochopiteľné. Ale nefunguje to.

Problém nie je v konfigurácii batchu. Nie je v parametri, na ktorý sme zabudli. Je v samotnej architektúre transportného pipeline Exchange, ktorý je pri každej migrácii rovnaký. Opätovné spustenie batchu prinesie presne rovnaký výsledok: rovnaké hlavičky Received: s novým dátumom migrácie a rovnaké nesprávne INTERNALDATE. Stratíte čas a používatelia budú zbytočne vyrušení druhýkrát.

Niektorí admini sa pokúšajú aj zmeniť nastavenia triedenia v Outlooku ("triediť podľa dátumu odoslania" namiesto "dátumu prijatia"). Triedenie podľa dátumu odoslania nie je riešením. Je to náplasť. Hlavička Date: a INTERNALDATE zostávajú nesprávne pre klientov, ktorí toto nastavenie neumožňujú, pre OWA, pre Outlook Mobile a pre každú aplikáciu tretej strany, ktorá pristupuje k schránke cez IMAP alebo EWS.

Čo sa skutočne deje v hlavičkách

Tu je zjednodušený príklad toho, čo obsahuje email po migrácii cez EAC. Pôvodná hlavička:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@stara-domena.sk
Subject: Správa Q1 2019

Po migrácii správa dostane na začiatok reťazca niečo takéto:

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

Outlook vidí túto hlavičku Received: ako prvú (pridáva sa na začiatok bloku hlavičiek), interpretuje ju ako najnovší dátum spracovania správy a zobrazí ju ako dátum prijatia. Pôvodná hlavička Date: z roku 2019 je stále tam, nedotknutá, o niekoľko riadkov nižšie. Ale Outlook ju nepoužíva pri zobrazovaní v zozname správ.

Aby sme boli presní: správanie sa mierne líši podľa verzie Outlooku. Verzie po roku 2021 (a obzvlášť nový Outlook pre Windows nasadený od konca roku 2023) sú na tento problém obzvlášť citlivé, pretože sa viac spoliehajú na metadáta Exchange Graph než na surové hlavičky Date:. To znamená, že migrácie, ktoré s Outlookom 2016 nespôsobovali viditeľný problém, môžu teraz s novým Outlookom problém spôsobovať.

Koho sa to skutočne týka

Najbežnejšie zdrojové IMAP servery pri tomto type migrácie sú Dovecot (veľmi rozšírený v prostredí Linux/cPanel) a Courier. Oba sprístupňujú INTERNALDATE cez IMAP, ktorý EAC nezachováva. Ak migrujete z lokálneho Exchange servera na Exchange Online (hybridná alebo cutover migrácia), správanie je odlišné, pretože Microsoft používa interný transportný protokol (MAPI/EWS), ktorý metadáta lepšie zachováva. Problém spôsobuje generická migrácia IMAP cez EAC.

Najviac postihnutí sú používatelia so schránkami s dlhou históriou (5 rokov a viac) a vysokým objemom správ. Používateľ s 300 emailmi to zvládne rýchlo. Obchodný riaditeľ s 12 000 emailmi trienenými podľa dátumu, na ktoré sa denne spolieha pri hľadaní komunikácie s klientmi, je ochrnutý.

Prečo je vlastný skript zlý nápad

Niektorí IT admini, ktorí chápu technický problém, sú pokúšaní napísať PowerShell alebo Python skript na manuálnu opravu hlavičiek. Základný koncept sa môže zdať jednoduchý po identifikácii mechanizmu. Ale realita opravy v produkčnom prostredí je iná vec.

Najprv hraničné prípady. Emaily podpísané S/MIME a správy šifrované PGP majú štruktúru, ktorá netoleruje úpravu hlavičiek bez zneplatnenia podpisu. Správy multipart/alternative s nesprávne formátovanými hranicami MIME (časté na starých Courier serveroch) môžu byť poškodené skriptom, ktorý správu upraví bez správnej rekonštrukcie štruktúry. Hlavičky s non-ASCII kódovaním podľa RFC 2047 (mená odosielateľov s diakritikou alebo japonskými znakmi napríklad) sú klasickým zdrojom chýb.

Potom objem. Skript, ktorý funguje na 50 testovacích emailoch vo vývojovom prostredí, nezvláda limity rýchlosti API Exchange Online v produkcii. Chyba 429 Too Many Requests o 2:00 v noci počas batchu 8 000 správ, bez mechanizmu obnovenia, znamená prebdenú noc a potenciálne duplikované alebo stratené správy.

A hlavne: ako overíte, že každý opravený email je neporušený? Že žiadna príloha nebola skrátená, že žiadne vlákno diskusie nie je prerušené, že štítky a priečinky sú zachované? Bez individuálneho mechanizmu overovania len dúfate, že všetko prebehlo dobre.

Oprava dátumov po migrácii je problém, ktorý vyzerá ako 50-riadkový skript, ale v produkcii si vyžaduje tisíce riadkov na spoľahlivú prevádzku.

Čo Redate.io robí inak

Redate.io sa pripojí k Exchange Online cez Microsoft 365 API (Azure Active Directory, delegované oprávnenia na úrovni tenanta) a naskenuje dotknuté schránky na identifikáciu emailov, ktorých metadáta dátumov boli migráciou poškodené. Táto fáza skenovania je bezplatná a poskytuje presný prehľad rozsahu problému: počet dotknutých správ, postihnuté schránky, rozsah poškodených dátumov.

Proprietárny korekčný engine Redate.io potom spracuje každý email individuálne cez viacstupňový analytický pipeline, ktorý zahŕňa porovnávanie vzorov so signatúrami známych migračných nástrojov (vrátane transportného pipeline Exchange Online), validáciu zhody s RFC a overenie štrukturálnej integrity správy pred opravou aj po nej. Emaily podpísané S/MIME, komplexné MIME štruktúry, nestandardné kódovania: všetky sú spracované špecifickými cestami spracovania.

Každá opravená správa je overená individuálne. Originály sú uchovávané v viditeľnom záložnom priečinku po dobu 30 dní. Ak niečo nie je v poriadku s konkrétnou správou, neopraví sa: Redate.io nahlási anomáliu namiesto riskovania poškodenia.

Ceny sú založené na objeme, formou jednorazovej platby za schránku. Žiadne predplatné, žiadne opakujúce sa poplatky. Problém opravíte raz a je hotovo.

Pre migrácie Exchange Online konkrétne Redate.io podporuje pripojenie cez oprávnenia aplikácie Azure AD (bez nutnosti vytvárať individuálne poverenia pre každú schránku), čo výrazne uľahčuje spracovanie veľkých flotíl schránok pre IT admina alebo MSP.

Ak spravujete viacerých klientov, ktorí podstúpili tento typ migrácie, pozrite si tiež kompletného sprievodcu opravou dátumov po migrácii na Microsoft 365 pre prehľad rôznych pokrytých scenárov.

Emaily sú tam, pôvodné dátumy tiež. Spustite bezplatné skenovanie na Redate.io a zistite presne, koľko správ je postihnutých vo vašich schránkach Exchange Online, skôr než sa rozhodnete čo robiť.