Zdieľaný hosting na Microsoft 365: skrytý problém s dátumami

Problém, ktorý vám nikto nespomínal

Práve ste dokončili migráciu pošty z OVH, Infomaniak, Ionos alebo o2switch do Microsoft 365. Migračný asistent v EAC (Exchange Admin Center) bežal celú noc, všetko je zelené, schránky sú naplnené. V pondelok ráno príde prvý tiket: "Všetky moje staré e-maily majú dnešný dátum." Potom druhý. Potom desať.

Nejde o chybu Microsoft 365. Nie je to ani náhoda. Je to mechanický dôsledok IMAP migrácie, a v prípade zdieľaného hostingu je problém často dvojnásobne závažnejší ako pri klasickej migrácii. Tu je dôvod.

Ako IMAP pracuje s dátumami (a kde sa to kazí)

Každý e-mail uložený na IMAP serveri má dva odlišné typy datovania. Na jednej strane hlavička Date: (definovaná v RFC 2822), ktorá je súčasťou samotnej správy a udáva, kedy bola odoslaná alebo prijatá. Na druhej strane INTERNALDATE, metadáta na úrovni servera, ktoré zaznamenávajú, kedy bol e-mail uložený do schránky. Práve túto hodnotu používajú poštové klienty ako Outlook na triedenie a zobrazovanie e-mailov.

(Mimochodom, ak ste niekedy skúšali čítať surové hlavičky e-mailov v EAC, viete, že to nie je presne oddychové čítanie. Kľudne dvadsať až tridsať riadkov hlavičiek, než sa dostanete k obsahu.)

Keď migračný nástroj IMAP presúva správu z jednej schránky do druhej, musí INTERNALDATE v cieľovej schránke znovu vytvoriť. Niektoré nástroje to robia správne. Mnohé nie, alebo to robia s obmedzeniami. A prijímacie servery majú tiež svoje slovo: Exchange Online napríklad si necháva to, čo dostane: keď kópia nesie svoj pôvodný dátum, tento dátum si zachová. Ak sú teda dátumy nesprávne, treba sa pozrieť na nástroj, nie na Microsoft 365.

Výsledok: každý migrovaný e-mail vyzerá, akoby bol "prijatý" v deň migrácie. Nezáleží na tom, že pochádza z roku 2019.

Scenár v dvoch krokoch: prečo zdieľané hostingy veci zhoršujú

Tu sa situácia stáva skutočne problematickou pri migráciách zo zdieľaných hostingov ako OVH, Infomaniak, Gandi, Ionos alebo o2switch.

Títo poskytovatelia zvyčajne používajú zdieľané servery Postfix, Dovecot alebo cPanel so štandardnými IMAP konfiguráciami. Mnoho malých a stredných firiem tu roky hromadilo e-maily, niekedy od roku 2010 alebo 2012. Keď sa rozhodnú prejsť na Microsoft 365, migrácia prebieha často v dvoch fázach.

Krok 1: prvé poškodenie (ešte pred Microsoft 365)

V mnohých prípadoch už e-maily zažili prvú migráciu. Firma v priebehu rokov raz-dvakrát zmenila hosting: z Gandi na OVH v roku 2018, potom z OVH na Infomaniak v roku 2022, napríklad. Každý IMAP presun mohol resetovať pôvodný INTERNALDATE na deň prenosu (pokiaľ nástroj neprenesie pôvodný dátum), a niektoré nástroje k tomu pridávajú aj vlastné migračné hlavičky datované týmto dňom.

Keď e-maily dorazí do Microsoft 365, nesú so sebou jazvy. Pôvodná hlavička Date: je neporušená (je súčasťou tela správy, nikto sa jej nedotkol), ale metadáta dátumu boli už raz narušené.

Krok 2: druhé poškodenie pri prechode na Exchange Online

Migračný nástroj IMAP v EAC, alebo nástroj tretej strany ako BitTitan MigrationWiz v IMAP režime, potom spracuje tieto už poškodené e-maily. Ak ani tento nástroj neprenesie pôvodný dátum každého e-mailu, Exchange Online ho zaradí pod deň prenosu, a to je potom "dátum prijatia", ktorý Outlook zobrazí.

E-mail odoslaný v marci 2017 tak môže niesť dve vrstvy nesprávnych dátumov: migračné hlavičky z presunu v roku 2022 a dátum prijatia z migrácie na Microsoft 365 v roku 2024. Outlook zobrazí 2024. Používateľ vidí 2024. Je to nesprávne na dvoch úrovniach.

Vlastne, aby som bol presný: Outlook určuje zobrazený dátum na základe kombinácie INTERNALDATE zaznamenaného Exchange Online a prítomných hlavičiek. Ak však migračný nástroj neprenesie pôvodné dátumy, presun na Exchange Online pridáva novú vrstvu chýb nad tou starou.

Migračné nástroje a hostingy: rizikové kombinácie

Pri migráciách zo zdieľaných hostingov sa niektoré kombinácie objavujú veľmi často:

• OVH / Infomaniak / Ionos + IMAP nástroj z EAC: natívny nástroj Microsoftu je praktický, ale je známy tým, že pri objemných IMAP migráciách dátumy správne nezachováva.
• cPanel (o2switch, LWS, atď.) + BitTitan MigrationWiz v IMAP režime: MigrationWiz v IMAP režime pridáva vlastné migračné hlavičky. Výsledok je zdokumentovaný aj na stránke oprava dátumov BitTitan v Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync je výkonný nástroj, ale jeho práca s INTERNALDATE závisí od konfigurácie. Bez správnej voľby sa dátumy nezachujú. Pozrite si aj imapsync: dátumy nezachované.
• Akákoľvek manuálna migrácia drag-and-drop v Outlooku: ak niekto kopíroval celé priečinky pretiahnutím medzi dvoma kontami v Outlooku, INTERNALDATE každého e-mailu bol prepísaný dátumom kopírovania. Bez výnimky.

Spoločný menovateľ: všetky tieto metódy vyústia v Exchange Online s e-mailmi, ktorých dátum zobrazený v Outlooku nezodpovedá ničomu reálnemu.

Prečo je "opraviť to sám" zlý nápad vo väčšom meradle

Pochopiť problém je jedna vec. Opraviť 8 000 e-mailov rozdelených do 40 schránok Exchange Online, na kontách s komplexnou štruktúrou priečinkov, e-mailmi podpísanými S/MIME, objemnými prílohami a vnorenými vláknami konverzácií, to je vec úplne iná.

PowerShell skript, ktorý zdanlivo funguje na desiatich testovacích e-mailoch, môže potichu zlyhať na správe číslo 4237 kvôli poškodenej hranici MIME alebo hlavičke enkódovanej podľa RFC 2047 (ten formát =?UTF-8?B?...?= pre znaky mimo ASCII v menách odosielateľov). Bez mechanizmu individuálneho overenia to nezistíte. Budete mať jednoducho stratený e-mail.

Konkrétne riziká vlastného riešenia pri tomto type migrácie:

• Duplicitné správy, ak logika vkladania zlyhá v polovici
• Chýbajúce prílohy, ak sa multipart štruktúra nesprávne zrekonštruuje
• Poškodené vlákna konverzácií v Outlooku (konverzácie sa opierajú o hlavičky References: a In-Reply-To:, ktoré môžu byť pozmenené)
• Chyby 429 (Too Many Requests) z Microsoft Graph API o 3:00 ráno, ktoré prerušia spracovanie bez možnosti vrátenia
• Žiadny jednoduchý spôsob, ako overiť, že všetkých 8 000 opráv bolo správne aplikovaných

A v špecifickom prípade migrácií zo zdieľaných hostingov je tu ešte jedna ťažkosť: e-maily nesú viacero vrstiev parazitných hlavičiek Received:, nie len jednu. Jednoduchý skript, ktorý odstráni "poslednú Received:" nestačí. Treba analyzovať celý reťazec, identifikovať, ktorá hlavička zodpovedá ktorej migrácii, a ktorá skutočne predstavuje pôvodný dátum prijatia.

Čo robí Redate.io inak

Každý používateľ sa prihlási svojím vlastným kontom Microsoft a Redate.io otvorí danú schránku s oprávneniami, ktoré toto prihlásenie udeľuje. Úvodný sken je bezplatný: Redate.io identifikuje všetky e-maily, u ktorých zobrazený dátum nezodpovedá skutočnému dátumu, a poskytne presný odhad podľa schránky.

Oprava sa opiera o proprietárny engine, ktorý analyzuje celý reťazec hlavičiek každej správy, bez ohľadu na to, aký migračný nástroj bol použitý, a správne rekonštruuje metadáta dátumu, aj keď sa na sebe nachádza viacero vrstiev poškodenia. Každý opravený e-mail je individuálne overený. Redate.io originály nikdy nemaže. Zostávajú vo viditeľnom priečinku vašej vlastnej schránky, kým ich sami neodstránite.

Pre migrácie zo zdieľaných hostingov viacstupňový analyzačný pipeline Redate.io explicitne rieši scenáre dvojitého poškodenia: nepozerá sa len na poslednú hlavičku Received:, ale prehľadáva celú históriu, aby našiel skutočný dátum prijatia. Pozrite si aj ako opraviť dátumy po migrácii na Microsoft 365 vo všeobecnosti, a špecifický sprievodca o poškodených INTERNALDATE v IMAP pre pochopenie základnej mechaniky.

Pred migráciou alebo po nej: dve chvíle na konanie

Dve situácie, dva prístupy.

Ešte ste nemigrovali. Dobrá správa: škody sa dajú obmedziť. Niektoré migračné nástroje (MigrationWiz v Exchange režime, CloudM so správnymi nastaveniami) zachovávajú dátumy lepšie ako iné. Ale aj v najlepšom prípade migrácia zo zdieľaného hostingu bez čistej histórie pravdepodobne zanechá stopy. Naplánujte si prechod cez Redate.io po migrácii, ešte predtým, než odovzdáte schránky používateľom.

Už ste migrovali a tikety prichádzajú. Redate.io opravuje existujúce schránky v Microsoft 365 bez ohľadu na to, kedy migrácia prebehla. Sken vám poskytne presný obraz skutočného stavu každej schránky ešte pred akýmkoľvek zásahom. Pozrite si aj checklist migrácie e-mailov, aby ste v budúcnosti predišli rovnakým problémom.

Migrovali ste z OVH, Infomaniak, Ionos alebo o2switch do Microsoft 365 a dátumy sú nesprávne? Vytvorte si účet Redate.io a naskenujte svoje schránky bezplatne, aby ste videli presný rozsah problémov ešte predtým, než sa rozhodnete pre akýkoľvek ďalší krok.