Outlook: dátum prijatia IMAP vs dátum odoslania

Príznak, ktorý pozná každý

Práve ste dokončili migráciu IMAP do Microsoft 365 alebo Google Workspace. V pondelok ráno začínajú prichádzať tikety: "Všetky moje emaily majú rovnaký dátum", "Môj archív je rozbitý", "V schránke sa neviem vyznať". Otvoríte Outlook a naozaj, tisíce emailov zobrazujú dátum minulého víkendu. Nie dátum odoslania. Dátum, kedy prebehla migrácia.

Nie je to chyba Outlooku. Je to priamy dôsledok fungovania protokolu IMAP a migračných nástrojov. Aby sme pochopili prečo, musíme otvoriť kapotu.

Tri dátumy v jednom emaili

Email je zložitejší, než sa zdá. Hlavička, telo správy, prílohy... a niekoľko rôznych časových pečiatok, ktoré v ňom žijú vedľa seba. (Ak ste niekedy skúšali čítať surové hlavičky emailu, viete, že to nie je presne oddychové čítanie.)

Hlavička Date: (RFC 2822)

To je dátum, ktorý odosielateľ vložil do správy v momente odoslania. Definovaný štandardom RFC 2822 vyzerá takto:

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

Táto hlavička je vtlačená priamo do tela správy. Nikdy sa nemení, pokiaľ niekto nezasahuje do surového obsahu emailu. To je "dátum odoslania" v pravom zmysle slova.

Hlavička Received: (pridaná pri každom sieťovom skoku)

Každý server, ktorý sa dotkne emailu počas prepravy, pridá na začiatok správy hlavičku Received: s vlastným dátumom. Email, ktorý prejde cez tri servery, nahromadí tri takéto hlavičky. Najnovšia je vždy na vrchu. Výsledok vyzerá 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)

Keď migračný nástroj ako BitTitan MigrationWiz, CloudM, imapsync alebo GSMMO presúva email zo zdrojového servera na cieľový, správa sa taktiež ako "sieťový skok". Injektuje novú hlavičku Received: na vrchol zásobníka, s dátumom a časom migrácie.

IMAP INTERNALDATE

To je tretí dátum a práve ten spôsobuje problémy. INTERNALDATE je metadáta uložené na strane IMAP servera, nezávisle od obsahu správy. Reprezentuje dátum, kedy bol email doručený (alebo vložený) do poštovej schránky. Keď migračný nástroj vkladá email cez príkaz IMAP APPEND, sám rozhoduje, akú hodnotu priradí INTERNALDATE. A v mnohých prípadoch nástroje používajú dátum migrácie. Nie pôvodný dátum.

Tam sa všetko zasekne.

Prečo Outlook zobrazuje dátum migrácie

Outlook používa INTERNALDATE na zobrazenie stĺpca "Prijaté". Toto je jeho predvolené správanie, ktoré je v súlade so špecifikáciou IMAP: INTERNALDATE má reprezentovať dátum prijatia do schránky. V bežnom priebehu (skutočný email, ktorý dorazí) je INTERNALDATE blízko dátumu v hlavičke Date:. Obe hodnoty sú konzistentné.

Po neúspešnej migrácii INTERNALDATE všetkých importovaných emailov ukazuje na noc zo 14. na 15. júna 2024 (alebo na akýkoľvek iný dátum migrácie). Outlook túto hodnotu načíta, zobrazí ju v stĺpci "Prijaté" a výsledok je katastrofálny: 45 000 emailov akoby prišlo v rovnakú noc.

Presnejšie povedané, prvá hlavička Received: (najnovšia v zásobníku) tiež ovplyvňuje zobrazenie v niektorých konfiguráciách. Ale INTERNALDATE zostáva hlavným determinantom pre stĺpec "Prijaté" v Outlooku v synchronizovanom IMAP režime.

Obídenie: "Pridať stĺpec Odoslané" v Outlooku

Prvá vec, ktorú väčšina IT administrátorov urobí po objavení problému, je hľadanie obídenia na strane klienta. A jedno existuje.

V Outlooku je možné upraviť zobrazenie stĺpcov priečinka a nahradiť (alebo doplniť) stĺpec "Prijaté" stĺpcom "Dátum" alebo "Odoslané". Stĺpec "Dátum" číta priamo hlavičku Date: správy, nie INTERNALDATE. Keďže hlavička Date: nebola migráciou dotknutá, pôvodné dátumy sa objavia.

V Outlooku (desktopová verzia, Microsoft 365) to spravíte takto: pravý klik na hlavičku stĺpca v zozname správ, "Nastavenia zobrazenia", potom upraviť stĺpce tak, aby ste odobrali "Prijaté" a pridali "Dátum". Dá sa to nasadiť cez GPO pre hromadné nasadenie.

Dobre. Na papieri to vizuálny problém rieši. V praxi je to náplasť na tepnicu.

Konkrétne limity tohto obídenia

Mobilní a weboví klienti

Outlook na iOS, Androide a Outlook Web App (OWA) nemajú rovnaké možnosti prispôsobenia. Zmena zobrazenia nasadená na Windows zariadeniach sa neprenáša. Používatelia, ktorí kontrolujú emaily na telefóne, naďalej vidia dátum migrácie. V stredne veľkej firme je to pravdepodobne polovica používateľov.

Vyhľadávanie

Vyhľadávanie v Outlooku používa index Windows Search (alebo index Exchange/Microsoft 365 na strane servera). Tento index je postavený na INTERNALDATE, nie na hlavičke Date:. Ak používateľ hľadá "emaily z januára 2022", vyhľadávanie vráti emaily, ktorých INTERNALDATE je v januári 2022. Nie tie, ktorých hlavička Date: je z januára 2022. Výsledok: staré emaily sa neobjavujú v dátumových filtroch. Zmena zobrazovacieho stĺpca na tom nič nemení.

Pravidlá pre správy

Pravidlá Outlooku ("ak bol email prijatý pred...", "ak bol email prijatý po...") tiež používajú INTERNALDATE. Pravidlo triedenia alebo archivácie založené na rozsahoch dátumov nebude po migrácii fungovať správne, ak INTERNALDATE nebola opravená.

Súlad s predpismi a eDiscovery

To je možno najvážnejší bod. Nástroje pre compliance, právne archivácie a eDiscovery (napríklad Microsoft Purview) používajú INTERNALDATE ako referenčný dátum pri právnych dopytoch. Ak vaša firma podlieha povinnostiam uchovávania dát alebo musí odpovedať na discovery žiadosti, poškodené INTERNALDATE môžu spôsobiť skutočné právne problémy. Audit, ktorý požaduje "všetky emaily medzi takým a takým dátumom", nevráti správne výsledky.

Nástroje tretích strán

CRM systémy, tiketing nástroje, archivátory... všetko, čo sa pripája k vášmu mailovému serveru cez IMAP alebo API Microsoft 365/Google Workspace, číta INTERNALDATE. Zmena zobrazenia v Outlooku neopraví nič pre tieto systémy.

Jediné skutočné riešenie: oprava na úrovni servera

Triedenie podľa dátumu odoslania v Outlooku nie je riešenie. Je to náplasť. Skutočná oprava musí prebehnúť na úrovni metadát servera, nie na úrovni klientskeho zobrazenia.

Konkrétne to znamená opraviť INTERNALDATE každého emailu tak, aby zodpovedala pôvodnému dátumu z hlavičky Date:. Pôvodná hlavička Date: je v správe vždy prítomná (migrácia ju nevymazala), čo opravu umožňuje. Tam sa nachádza skutočná informácia o dátume.

Na Google Workspace API Gmail vystavuje parameter internalDate, ktorý umožňuje priamo zasahovať do tejto metadáty. Na Microsoft 365 je mechanizmus odlišný, ale očakávaný výsledok je rovnaký. Na štandardnom IMAP serveri norma umožňuje špecifikovať dátum pri vkladaní správy.

V praxi vykonať túto operáciu na desiatky tisíc emailov v produkcii, bez straty dát, bez duplikátov, bez rozbitia vlákien diskusií alebo štítkov, so správaním hraničných prípadov (S/MIME podpísané správy, komplexné MIME štruktúry, non-ASCII kódovania podľa RFC 2047, veľké prílohy)... to je úplne iná vec. Skript, ktorý funguje na 50 testovacích emailoch, nevydrží na schránke so 40 000 správami. Správa chýb 429 (prekročená API kvóta), sieťové timeouty o druhej v noci, správy s MIME štruktúrou čiastočne poškodenou po migrácii... to všetko si vyžaduje serióznu inžiniersku prácu.

Presne to robí Redate.io. Proprietárny opravný engine analyzuje reťazec hlavičiek každého emailu, identifikuje spoľahlivý pôvodný dátum a aplikuje cielenú opravu metadát bez zásahu do obsahu správy. Každý opravený email je overený individuálne. Originály sú uchovávané v záložnom priečinku 30 dní, čo umožňuje rollback kedykoľvek. Niečo, čo domáci skript nikdy neponúkne.

Identifikácia zodpovedného migračného nástroja

Problém sa prejavuje rovnako bez ohľadu na pôvod migrácie, ale detaily sa líšia podľa použitého nástroja. BitTitan MigrationWiz, CloudM, imapsync a GSMMO majú každý svoju signatúru v hlavičkách Received:, ktoré injektujú. Analytický pipeline Redate.io udržiava databázu zhôd na stovkách signatúr známych migračných nástrojov, aby odlíšil migračnú hlavičku od zvyšku legitímneho tranzitného reťazca.

Ak neviete, ktorý nástroj bol na vašu migráciu použitý (stáva sa to, najmä keď preberáte infraštruktúru po inom MSP), bezplatný sken Redate.io identifikuje postihnuté schránky a pred akýmkoľvek záväzkom odhadne objem na opravu.

Pre konkrétne kontexty sú k dispozícii podrobné návody: oprava dátumov imapsync v Outlooku, oprava dátumov BitTitan v Outlooku alebo oprava dátumov CloudM v Outlooku.

Čo urobiť teraz

Ak čítate tento článok po migrácii, dobrá správa je, že pôvodná hlavička Date: je neporušená v každom z vašich emailov. Skutočné informácie o dátume sú tam, prítomné v každej správe. Problém je v metadátach, nie v obsahu. A metadáta sa dajú opraviť.

Môžete si tiež prečítať článok IMAP INTERNALDATE: prečo sa dátumy pokazia pre hlbší pohľad na mechaniku problému, alebo kompletného sprievodcu nesprávnymi dátumami v Outlooku po migrácii ak chcete prehľad všetkých prípadov.

Pripravení opraviť dátumy vo vašich poštových schránkach? Spustite bezplatný sken na Redate.io a identifikujte postihnuté emaily a odhadnite objem pred akoukoľvek opravou.