Nesprávne dátumy emailov po migrácii - príčiny a riešenia

Problém - všetky e-maily zobrazujú rovnaký dátum

Po IMAP migrácii používatelia otvoria svoju poštovú schránku a objavia znepokojujúci stav: každý e-mail zobrazuje presne ten istý dátum. Namiesto pôvodného dátumu odoslania alebo prijatia všetky správy nesú dátum, kedy bola migrácia vykonaná. Roky korešpondencie, ktoré vyzerajú, akoby prišli v ten istý deň.

Pre IT administrátorov je to nočná mora. Tikety sa hromadia, používatelia nevedia nič nájsť podľa dátumu a chronologická história poštovej schránky je v praxi zničená.

Ako to vyzerá v Outlooku

V Microsoft Outlooku stĺpec "Prijaté" zobrazuje dátum migrácie pri každom e-maili. Či bola správa odoslaná v roku 2018 alebo 2023, Outlook ukazuje ten istý dátum, deň kedy migračný nástroj spracoval poštovú schránku. Doručená pošta, odoslané položky, každý priečinok je postihnutý. Používatelia, ktorí sa spoliehajú na triedenie podľa dátumu, majú pracovný postup úplne narušený.

Ako to vyzerá v Apple Mail

Apple Mail na macOS a iOS sa správa podobne. Zobrazený dátum pri každej správe odráža časovú pečiatku migrácie namiesto pôvodného dátumu. Keďže Apple Mail využíva metaúdaje IMAP servera na určenie zobrazovaných dátumov, ten istý základný problém produkuje ten istý viditeľný výsledok. Pri prehliadaní doručenej pošty vidíte len stenu rovnakých dátumov.

Ako to vyzerá v Gmail (webové rozhranie)

Webové rozhranie Gmailu predstavuje mierne odlišnú situáciu. Webový klient Gmailu zvyčajne používa hlavičku "Date" zo samotného e-mailu, takže správy sa môžu zobraziť so správnym dátumom v Gmaili. Ale IMAP INTERNALDATE zostáva nesprávna, čo znamená, že každý IMAP klient pripojený k tomuto Gmail účtu (Outlook, Thunderbird, Apple Mail) zobrazí dátum migrácie. Takže tá istá poštová schránka vyzerá správne v jednom klientovi, ale nesprávne v inom. Vlastne dosť mätúce.

Prečo sa to deje - technická príčina

Hlavná príčina spočíva v tom, ako migračné nástroje IMAP spracovávajú hlavičky e-mailov a ako e-mailoví klienti určujú, ktorý dátum zobraziť. Pochopenie tohto vyžaduje krátky pohľad na protokol IMAP a štruktúru hlavičiek.

Ako migračné nástroje IMAP spracovávajú hlavičky

Keď sa e-mail migruje z jedného servera na druhý, migračný nástroj stiahne surovú správu zo zdrojového servera a nahrá ju na cieľový server pomocou príkazu IMAP APPEND. Počas tohto procesu protokol IMAP vyžaduje, aby cieľový server pridal k správe hlavičku "Received". Táto hlavička obsahuje časovú pečiatku momentu vloženia správy do nového servera, teda dátum migrácie.

Hlavička "Received", ktorá rozbije všetko

E-mailové správy zvyčajne obsahujú viacero hlavičiek "Received", každá pridaná poštovým serverom, ktorý správu spracoval počas jej pôvodného doručenia. Klienti ako Outlook určujú "dátum prijatia" čítaním najnovšej hlavičky "Received", tej na vrchu reťazca. Keď migračný nástroj pridá novú hlavičku "Received" s časovou pečiatkou migrácie, stane sa najnovšou a e-mailoví klienti zobrazia tento dátum namiesto pôvodného.

Nejde o chybu migračného nástroja ani e-mailového klienta. Oba správne dodržiavajú štandardy IMAP a e-mailov. Problém je v tom, že tieto štandardy nikdy neboli navrhnuté pre hromadnú migráciu a interakcia medzi IMAP APPEND a logikou zobrazovania dátumov produkuje tento nežiaduci výsledok.

INTERNALDATE vs hlavička Date

IMAP servery uchovávajú dve rôzne hodnoty dátumu pre každú správu. Hlavička "Date" je súčasťou samotnej e-mailovej správy, zaznamenáva, kedy bola správa pôvodne napísaná a odoslaná. INTERNALDATE sú metaúdaje uchovávané IMAP serverom, reprezentujúce kedy bola správa doručená alebo vložená na tento konkrétny server.

Niektoré migračné nástroje sa pokúšajú zachovať pôvodnú INTERNALDATE jej nastavením počas príkazu APPEND. Ale aj keď je INTERNALDATE správne nastavená, pridaná hlavička "Received" stále spôsobuje problémy v klientoch, ktorí uprednostňujú dátum "Received" pred INTERNALDATE.

Ktoré migračné nástroje spôsobujú tento problém?

Takmer každý migračný nástroj IMAP môže spôsobiť tento problém. Problém je inherentný protokolu IMAP, nie špecifický pre konkrétny nástroj. Niektoré sú však častejšie spojené s problémom kvôli ich širokému používaniu.

BitTitan MigrationWiz

BitTitan MigrationWiz je jedným z najpopulárnejších komerčných migračných nástrojov používaných MSP a IT konzultantmi. MigrationWiz pridáva hlavičku "Received" obsahujúcu "mx.migrationwiz.com" počas migračného procesu. Táto hlavička sa stáva najnovšou v reťazci, čo spôsobuje zobrazenie dátumu migrácie v Outlooku a iných IMAP klientoch. Pozrite si podrobné návody na opravu dátumov BitTitan v Outlooku, Microsoft 365, Google Workspace a Exchange Online.

CloudM Migrate

CloudM Migrate (predtým Cloud Migrator) je široko používaný pri migráciách na Google Workspace. Rovnako ako iné nástroje, aj CloudM pridáva svoju vlastnú hlavičku "Received" počas IMAP inserovania. E-maily migrované cez CloudM zobrazujú dátum migrácie v klientoch, ktorí sa spoliehajú na hlavičku "Received". Pozrite si návody na opravu dátumov CloudM v Gmaili, Outlooku, Google Workspace a Microsoft 365.

imapsync

imapsync je open-source nástroj populárny medzi Linux administrátormi a hostingovými poskytovateľmi. Hoci sa imapsync pokúša zachovať INTERNALDATE, cieľový server stále pridáva hlavičku "Received" počas operácie APPEND. FAQ imapsync toto obmedzenie uznáva, ale neponúka vstavané riešenie na odstránenie pridanej hlavičky po migrácii. Pozrite si návody na opravu dátumov imapsync v Outlooku, Gmaili, Microsoft 365 a Google Workspace.

GSMMO (Google Workspace Migration)

Google Workspace Migration for Microsoft Outlook (GSMMO) je vlastný nástroj Googlu na migráciu z Exchange alebo súborov PST Outlooku do Google Workspace. GSMMO môže spôsobiť ten istý problém s dátumom, najmä keď migrácia zahrňa medziľahlý IMAP krok. Pozrite si návody na opravu dátumov GSMMO v Outlooku, Gmaili a Apple Mail.

Exchange Admin Center (natívny IMAP import)

Centrum správy Exchange od Microsoftu zahrňa natívnu funkciu importu IMAP na migráciu do Exchange Online (Microsoft 365). Tento vstavaný migračný nástroj pridáva hlavičky "Received" počas importu, čo spôsobuje rovnaký problém so zobrazením dátumov. Pozrite si návody na opravu dátumov migrácie Exchange IMAP v Outlooku a OWA.

Manuálne kopírovanie IMAP

Dokonca aj manuálne kopírovanie e-mailov medzi IMAP servermi cez klienta ako Thunderbird môže spôsobiť tento problém s dátumom. Keď e-mailový klient kopíruje správu cez IMAP, cieľový server ju spracuje ako nové vloženie a pridá svoju vlastnú hlavičku "Received" s aktuálnou časovou pečiatkou. Pozrite si návody na opravu dátumov manuálneho IMAP kopírovania v Outlooku, Gmaili, Thunderbirde a Apple Mail.

Prečo bežné obchádzky nefungujú

Tvárou v tvár tomuto problému používatelia aj administrátori zvyčajne skúšajú niekoľko prístupov, než si uvedomia, že žiadny skutočne problém nerieši.

"Trieďte podľa dátumu odoslania" - prečo to nestačí

Najčastejší návrh je prepnúť triedenie z dátumu "prijatia" na dátum "odoslania" v e-mailovom klientovi. To síce zmení poradie zobrazovania, ale neopraví základné údaje. Výsledky vyhľadávania stále ukazujú nesprávny dátum. Integrácia s kalendárom, nástroje na dodržiavanie predpisov a automatizované pracovné postupy závisajúce od dátumu prijatia naďalej nefungujú správne. A používatelia musia myslieť na zmenu tohto nastavenia na každom zariadení a v každom priečinku.

Opakovaná migrácia - nákladná a riziková

Niektorí administrátori zvažujú zopakovanie migrácie v nádeji, že sa problému s dátumom druhý raz vyhnú. Tento prístup je nákladný (500 až 5 000 EUR podľa počtu schránok), časovo náročný a riskantný. Druhá migrácia prináša ten istý problém s hlavičkou "Received", zdvojnásobuje riziko straty údajov a vyžaduje významný výpadok. Opakovaná migrácia problém s dátumom nerieši, pokiaľ nie je migračný nástroj zásadne zmenený.

Manuálna úprava hlavičiek - vyžaduje prístup k serveru

Technicky korekcia zahrňa odstránenie migračnej hlavičky "Received" z každého e-mailu. Ale robiť to manuálne vyžaduje priamy prístup k serveru, znalosť štruktúry e-mailových hlavičiek a vlastný skript. Pri schránke s 10 000 e-mailmi je manuálna úprava nepraktická a nebezpečne náchylná na chyby. E-maily s podpismi S/MIME, šifrované správy PGP, multipart štruktúry s vnorenými MIME hranicami, problémy s Content-Transfer-Encoding, hlavičky s non-ASCII znakmi (RFC 2047), príliš veľké prílohy: každý z týchto prípadov môže spôsobiť, že základný skript nenávratne poškodí údaje. Ako potvrdíte, že 10 000 opravených e-mailov je všetkých neporušených? Nedá sa, ibaže s overovacím systémom navrhnutým špecificky na tento účel.

Skutočné riešenie - obnovenie pôvodných dátumov

Správny prístup spočíva v identifikácii migračných artefaktov v reťazci hlavičiek každého e-mailu a aplikovaní cielených korekcií, ktoré obnovia pôvodné chronologické zoradenie vo všetkých e-mailových klientoch. Nejde o jednoduchú úpravu hlavičiek. Proces zahrňa validáciu súladnosti s RFC, zachovanie štruktúry správy a porovnávanie podpisov migrácie z databázy známych profilov nástrojov.

Ako Redate.io opravuje tento problém

Redate.io sa pripojí k poštovej schránke (Google Workspace, Microsoft 365 alebo akýkoľvek IMAP server) a analyzuje každý e-mail na identifikáciu správ postihnutých migračnými hlavičkami. Analýza je bezplatná a ukazuje presne, koľko e-mailov je postihnutých, ešte pred akýmkoľvek platením.

Pre každý postihnutý e-mail proprietárny korekčný motor Redate.io spracuje správu cez viacstupňový analytický pipeline. Motor aplikuje porovnávanie podpisov na stovkách známych profilov migračných nástrojov, vytvorených zo spracovania veľkých objemov reálnych e-mailových údajov. Rieši problémy s kódovaním, multipart štruktúry, inline prílohy a desiatky okrajových prípadov, ktoré by spôsobili, že DIY skript poškodí údaje (nie ten typ zistenia, ktorý chcete v pondelok ráno). Každý opravený e-mail prechádza kontrolou integrity pred finalizáciou. Pôvodná správa sa presunie do viditeľného priečinka "Redate.io - Originals" (nie je zmazaná) a uchováva sa 30 dní.

Výsledok? E-maily zobrazujú svoje správne pôvodné dátumy vo všetkých klientoch. Triedenie opäť funguje. Chronologická história poštovej schránky je obnovená.

Často kladené otázky

Dajú sa dátumy opraviť mesiace po migrácii?

Áno. Pôvodná hlavička "Date" sa uchováva vo vnútri e-mailovej správy nezávisle od toho, kedy migrácia prebehla. Redate.io dokáže opraviť dátumy e-mailov týždne, mesiace alebo dokonca roky po migrácii. Korekcia funguje, pokiaľ sú pôvodné hlavičky e-mailu neporušené.

Zmaže korekcia dátumov moje e-maily?

Nie. Redate.io nikdy nemaže e-maily. Pôvodné správy sa presunú do viditeľného priečinka s názvom "Redate.io - Originals" v poštovej schránke, kde zostanú prístupné 30 dní. Každý opravený e-mail sa overuje oproti originálu pred finalizáciou procesu. Ak overenie pre nejakú správu zlyhá, originál zostane nedotknutý.

Funguje to so zdieľanými poštovými schránkami?

Áno. Redate.io funguje so zdieľanými poštovými schránkami v Google Workspace a Microsoft 365. Pre zdieľané schránky je potrebný prístup na úrovni administrátora na autorizáciu pripojenia. Proces je identický ako pri individuálnych schránkach: analýza, korekcia, overenie.

Ste pripravení obnoviť správne dátumy? Spustite bezplatnú analýzu a zistite, koľko e-mailov je postihnutých v každej poštovej schránke.