Sdílený hosting na Microsoft 365: skrytý problém s daty

Problém, který vám nikdo nenahlásil

Právě jste dokončili migraci pošty z OVH, Infomaniak, Ionos nebo o2switch do Microsoft 365. Průvodce migrací v EAC (Exchange Admin Center) běžel celou noc, všechno svítí zeleně, schránky jsou plné. V pondělí ráno přijde první ticket: "Všechny moje staré e-maily mají dnešní datum." Pak druhý. Pak deset.

Není to chyba Microsoft 365. Není to ani náhoda. Je to mechanický důsledek IMAP migrace, a v případě sdíleného hostingu je problém často dvakrát závažnější než u klasické migrace. Tady je proč.

Jak IMAP pracuje s daty (a kde to začne skřípat)

Každý e-mail uložený na IMAP serveru má dva odlišné typy datování. Na jedné straně je hlavička Date: (definovaná RFC 2822), která je součástí samotného těla zprávy a udává, kdy byla zpráva odeslána nebo přijata. Na druhé straně je INTERNALDATE, metadata na úrovni serveru, která říkají, kdy byl daný e-mail uložen do schránky. Právě tuto hodnotu používají poštovní klienti jako Outlook standardně pro řazení a zobrazování e-mailů.

(Mimochodem, pokud jste někdy zkusili číst raw hlavičky e-mailu v EAC, víte, že to není úplně plážové čtení. Než se dostanete k samotnému obsahu, projedete klidně dvacet až třicet řádků hlaviček.)

Když IMAP migrační nástroj přesune zprávu z jedné schránky do druhé, musí na cílovém serveru znovu vytvořit tento INTERNALDATE. Některé nástroje to dělají správně. Mnoho ne, nebo to dělají s omezeními. Přijímající server si ale ponechává to, co dostane: pokud kopie nese své původní datum, Exchange Online toto datum zachová. Když je tedy datum špatně, příčinou je nástroj, ne Microsoft 365.

Výsledek: každý migrovaný e-mail vypadá, jako by byl "přijat" v den migrace. Bez ohledu na to, že pochází z roku 2019.

Scénář ve dvou krocích: proč sdílený hosting vše zhoršuje

Tady se situace stává skutečně problematickou pro migrace ze sdílených hostingů jako OVH, Infomaniak, Gandi, Ionos nebo o2switch.

Tito poskytovatelé obvykle používají sdílené servery s Postfixem, Dovecot nebo cPanel se standardními IMAP konfiguracemi. Mnoho malých a středních firem tam nahromadilo roky e-mailové komunikace, někdy od roku 2010 nebo 2012. Když se rozhodnou přejít na Microsoft 365, migrace často probíhá ve dvou fázích.

Krok 1: první poškození (ještě před Microsoft 365)

V mnoha případech už e-maily prošly první migrací. Firma v průběhu let jednou nebo dvakrát změnila poskytovatele sdíleného hostingu: například z Gandi na OVH v roce 2018, pak z OVH na Infomaniak v roce 2022. Každý IMAP přesun mohl nastavit původní INTERNALDATE na den přesunu, pokud nástroj nepředal původní datum, a některé nástroje k tomu navíc přidávají vlastní migrační hlavičky orazítkované tímto dnem.

Když e-maily dorazí do Microsoft 365, nesou tedy již jizvy. Původní hlavička Date: je neporušená (je součástí těla zprávy, nikdo se jí nedotýká), ale datová metadata už byla jednou narušena.

Krok 2: druhé poškození při přechodu na Exchange Online

IMAP migrační nástroj z EAC, nebo nástroj třetí strany jako BitTitan MigrationWiz nakonfigurovaný v IMAP režimu, pak zpracovává tyto již poškozené e-maily. Pokud ani tento nástroj nepředá původní datum každého e-mailu, Exchange Online zařadí e-mail pod den přenosu, a to je "datum přijetí", které pak Outlook zobrazí.

E-mail odeslaný v březnu 2017 tak může nést dvě vrstvy špatných dat: migrační hlavičky zanechané přesunem v roce 2022 a datum přijetí z migrace do Microsoft 365 v roce 2024. Outlook zobrazí 2024. Uživatel vidí 2024. To je špatně hned na dvou úrovních.

Upřesněme: Outlook určuje zobrazené datum kombinací INTERNALDATE, které zaznamenal Exchange Online, a přítomných hlaviček. Pokud ale migrační nástroj nepředá původní datum, přesun na Exchange Online přidává novou vrstvu chyb přes tu starou.

Migrační nástroje a hostingové firmy: rizikové kombinace

Při migraci ze sdíleného hostingu se velmi často vyskytují tyto kombinace:

• OVH / Infomaniak / Ionos + IMAP nástroj EAC: nativní nástroj Microsoftu je praktický, ale je notoricky známý tím, že při objemných IMAP migracích nezachová data správně.
• cPanel (o2switch, LWS atd.) + BitTitan MigrationWiz v IMAP režimu: MigrationWiz v IMAP režimu přidává vlastní migrační hlavičky. Výsledek je zdokumentován mimo jiné na stránce jak opravit datum e-mailů po migraci BitTitan do Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync je výkonný nástroj, ale jeho správa INTERNALDATE závisí na konfiguraci. Bez správné volby data nejsou zachována. Viz také imapsync: data se nezachovala.
• Každá ruční migrace přetažením v Outlooku: pokud někdo kopíroval celé složky drag-and-dropem mezi dvěma účty nakonfigurovanými v Outlooku, INTERNALDATE každého e-mailu byl přepsán datem kopírování. Bez výjimky.

Společmenovatel: všechny tyto metody vedou na Exchange Online s e-maily, jejichž datum zobrazené v Outlooku neodpovídá ničemu reálnému.

Proč "opravit to sami" je špatný nápad ve velkém měřítku

Pochopit problém je jedna věc. Opravit 8 000 e-mailů rozložených ve 40 schránkách Exchange Online, na účtech s komplexními strukturami složek, e-maily podepsanými S/MIME, velkými přílohami a vnořenými vlákny konverzací, je věc úplně jiná.

PowerShell skript, který zdánlivě funguje na deseti testovacích e-mailech, může tiše selhat na zprávě číslo 4237 kvůli poškozené MIME hranici nebo hlavičce zakódované v RFC 2047 (ten formát =?UTF-8?B?...?= pro non-ASCII znaky v názvech odesílatelů). Bez mechanismu individuálního ověření to nezjistíte. Prostě budete mít jeden ztracený e-mail.

Konkrétní rizika DIY přístupu u tohoto typu migrace:

• Zdvojené zprávy, pokud logika vkládání selže v půlce cesty
• Chybějící přílohy, pokud je multipart struktura špatně rekonstruována
• Rozbité vlákna konverzací v Outlooku (konverzace se opírají o hlavičky References: a In-Reply-To:, které mohou být pozměněny)
• Chyby 429 (Too Many Requests) z Microsoft Graph API ve tři ráno, které přeruší zpracování bez možnosti vrácení zpět
• Žádný jednoduchý způsob ověření, že všech 8 000 oprav bylo aplikováno správně

A v konkrétním případě migrací ze sdíleného hostingu přibývá jedna další obtíž: e-maily nesou několik vrstev parazitních hlaviček Received:, ne jen jednu. Jednoduchý skript, který odstraní "poslední Received:", nestačí. Je třeba analyzovat celý řetězec a identifikovat, která hlavička odpovídá které migraci, a která skutečně představuje původní datum přijetí.

Co Redate.io dělá jinak

Redate.io se přihlašuje přes účet Microsoft každého uživatele a otevře tak přímo jeho schránku s oprávněními, která toto přihlášení uděluje. Žádný portál, žádná aplikace k registraci. Počáteční sken je zdarma: Redate.io identifikuje všechny e-maily, jejichž zobrazené datum neodpovídá skutečnému datu, a poskytne přesný odhad počtu na schránku.

Oprava stojí na proprietárním opravném enginu, který analyzuje úplný řetězec hlaviček každé zprávy, bez ohledu na použitý migrační nástroj rekonstruuje správné datum zprávy, a to i v případech, kdy se překrývá více vrstev poškození. Každý opravený e-mail je individuálně ověřen. Redate.io originály nikdy nemaže. Zůstávají ve viditelné záložní složce ve vaší schránce, dokud je sami neodstraníte.

Pro migrace ze sdíleného hostingu vícestupňový analytický pipeline Redate.io explicitně pracuje se scénáři dvojitého poškození: nekouká jen na poslední hlavičku Received:, ale prochází celou historii zpět, aby nalezl skutečné datum přijetí. Přečtěte si také obecný průvodce, jak opravit datum e-mailů po migraci Microsoft 365, a podrobnou stránku o poškozených INTERNALDATE v IMAP pro pochopení základní mechaniky.

Před migrací nebo po ní: dva momenty pro akci

Dvě situace, dva přístupy.

Ještě jste nemigrovali. Dobrá zpráva: škody jde omezit. Některé migrační nástroje (MigrationWiz v Exchange režimu, CloudM se správnými nastaveními) zachovávají data lépe než jiné. Ale i v nejlepším případě migrace ze sdíleného hostingu bez čistě vedeného historického záznamu pravděpodobně zanechá stopy. Počítejte s průchodem přes Redate.io po migraci, ještě před předáním schránek uživatelům.

Už jste migrovali a tickety přicházejí. Redate.io opravuje existující schránky v Microsoft 365 bez ohledu na to, jak stará migrace je. Sken Vám dá přesný obraz skutečného stavu každé schránky před jakýmkoli zásahem. Podívejte se také na checklist migrace e-mailů, abyste předešli stejným problémům v budoucnu.

Migrovali jste z OVH, Infomaniak, Ionos nebo o2switch do Microsoft 365 a data jsou špatná? Vytvořte si účet Redate.io a naskenujte schránky zdarma, abyste viděli přesný rozsah škod, než se rozhodnete cokoliv podniknout.