Problém - všechny e-maily zobrazují stejné datum
Po migraci IMAP uživatelé otevřou svou schránku a narazí na znepokojivý pohled: každý e-mail zobrazuje přesně stejné datum. Místo původního data odeslání nebo přijetí nesou všechny zprávy datum, kdy byla migrace provedena. Roky korespondence, které vypadají, jako by dorazily ve stejný den.
Pro IT administrátory je to noční můra. Tikety se hromadí, uživatelé nemohou nic najít podle data a chronologická historie schránky je v praxi zničená.
Jak to vypadá v Outlooku
V Microsoft Outlooku sloupec "Přijato" zobrazuje datum migrace u každého e-mailu. Ať byla zpráva odeslána v roce 2018 nebo 2023, Outlook ukazuje stejné datum - den, kdy migrační nástroj zpracoval schránku. Doručená pošta, odeslaná pošta, každá složka je zasažena. Uživatelé, kteří se spoléhají na řazení podle data, mají kompletně rozbitý pracovní postup.
Jak to vypadá v Apple Mail
Apple Mail na macOS a iOS se chová podobně. Datum zobrazené vedle každé zprávy odráží časové razítko migrace, nikoli původní datum. Protože Apple Mail používá metadata serveru IMAP k určení zobrazovaných dat, stejný základní problém produkuje stejný viditelný výsledek. Při procházení doručené pošty vidíte jen zeď identických dat.
Jak to vypadá v Gmailu (webové rozhraní)
Webové rozhraní Gmailu představuje mírně odlišnou situaci. Webový klient Gmailu obecně používá hlavičku "Date" samotného e-mailu, takže zprávy se mohou zobrazovat se správným datem v Gmailu. Ale IMAP INTERNALDATE zůstává chybný, což znamená, že jakýkoli IMAP klient připojený k tomuto účtu Gmail (Outlook, Thunderbird, Apple Mail) zobrazí datum migrace. Takže stejná schránka vypadá správně v jednom klientovi, ale špatně v jiném. Poněkud matoucí.
Proč k tomu dochází - technická příčina
Hlavní příčina spočívá ve způsobu, jakým migrační nástroje IMAP zacházejí s hlavičkami e-mailů, a v tom, jak poštovní klienti určují, které datum zobrazit. Pochopení tohoto problému vyžaduje krátký pohled na protokol IMAP a strukturu hlaviček.
Jak migrační nástroje IMAP zacházejí s hlavičkami
Když je e-mail migrován z jednoho serveru na druhý, migrační nástroj stáhne surovou zprávu ze zdrojového serveru a nahraje ji na cílový server pomocí příkazu IMAP APPEND. Během tohoto procesu protokol IMAP vyžaduje, aby cílový server přidal hlavičku "Received" ke zprávě. Tato hlavička obsahuje časové razítko okamžiku, kdy byla zpráva vložena do nového serveru, tedy datum migrace.
Hlavička "Received", která rozbije všechno
E-mailové zprávy obvykle obsahují několik hlaviček "Received", každou přidanou poštovním serverem, který zpracoval zprávu během jejího původního doručení. Klienti jako Outlook určují "datum přijetí" čtením nejnovější hlavičky "Received", té na vrcholu řetězce. Když migrační nástroj přidá novou hlavičku "Received" s časovým razítkem migrace, stane se nejnovější a poštovní klienti zobrazí toto datum místo původního.
Nejde o chybu migračního nástroje ani poštovního klienta. Oba správně dodržují standardy IMAP a e-mailu. Problém pochází z toho, že tyto standardy nikdy nebyly navrženy pro hromadnou migraci a interakce mezi IMAP APPEND a logikou zobrazení dat produkuje tento nežádoucí výsledek.
INTERNALDATE vs hlavička Date
Servery IMAP ukládají dvě různé hodnoty data pro každou zprávu. Hlavička "Date" je součástí samotné e-mailové zprávy a zaznamenává, kdy byla zpráva původně napsána a odeslána. INTERNALDATE je metadata uložená serverem IMAP, reprezentující kdy byla zpráva doručena nebo vložena na konkrétní server.
Některé migrační nástroje se pokoušejí zachovat původní INTERNALDATE nastavením během příkazu APPEND. Ale i když je INTERNALDATE správně nastaven, přidaná hlavička "Received" stále způsobuje problémy v klientech, kteří upřednostňují datum "Received" před INTERNALDATE.
Které migrační nástroje způsobují tento problém?
Téměř všechny migrační nástroje IMAP mohou způsobit tento problém. Potíž je vlastně inherentní protokolu IMAP, nikoli specifická pro konkrétní nástroj. Některé jsou však s tímto problémem spojovány častěji kvůli jejich rozšířenému použití.
BitTitan MigrationWiz
BitTitan MigrationWiz je jedním z nejpopulárnějších komerčních migračních nástrojů používaných MSP a IT konzultanty. MigrationWiz přidává hlavičku "Received" obsahující "mx.migrationwiz.com" během procesu migrace. Tato hlavička se stane nejnovější v řetězci, což způsobí zobrazení data migrace v Outlooku a dalších IMAP klientech. Viz podrobné návody pro opravu dat BitTitan v Outlooku, Microsoft 365, Google Workspace a Exchange Online.
CloudM Migrate
CloudM Migrate (dříve Cloud Migrator) je široce používán pro migrace Google Workspace. Stejně jako ostatní nástroje, CloudM přidává vlastní hlavičku "Received" při IMAP vložení. E-maily migrované pomocí CloudM zobrazují datum migrace v klientech, kteří se opírají o hlavičku "Received". Viz návody pro opravu dat CloudM v Gmailu, Outlooku, Google Workspace a Microsoft 365.
imapsync
imapsync je open-source nástroj oblíbený mezi Linux administrátory a poskytovateli hostingu. Přestože se imapsync pokouší zachovat INTERNALDATE, cílový server stejně přidá hlavičku "Received" během operace APPEND. FAQ imapsync toto omezení uznává, ale nenabízí vestavěné řešení pro odstranění přidané hlavičky po migraci. Viz návody pro opravu dat imapsync v Outlooku, Gmailu, Microsoft 365 a Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) je vlastní nástroj Googlu pro migraci z Exchange nebo souborů PST Outlooku do Google Workspace. GSMMO může způsobit stejný problém s datem, zejména když migrace zahrnuje přechodný krok přes IMAP. Viz návody pro opravu dat GSMMO v Outlooku, Gmailu a Apple Mail.
Exchange Admin Center (nativní IMAP import)
Centrum pro správu Exchange od Microsoftu obsahuje nativní funkci IMAP importu pro migraci do Exchange Online (Microsoft 365). Tento vestavěný migrační nástroj přidává hlavičky "Received" během importu, což způsobuje stejný problém se zobrazením data. Viz návody pro opravu dat migrace Exchange IMAP v Outlooku a OWA.
Ruční kopie IMAP
Dokonce i ruční kopírování e-mailů mezi servery IMAP přes klienta jako Thunderbird může způsobit tento problém s datem. Když poštovní klient kopíruje zprávu přes IMAP, cílový server ji zpracuje jako nové vložení a přidá vlastní hlavičku "Received" s aktuálním časovým razítkem. Viz návody pro opravu dat ruční kopie IMAP v Outlooku, Gmailu, Thunderbirdu a Apple Mail.
Proč běžná řešení nefungují
Tváří v tvář tomuto problému uživatelé a administrátoři obvykle zkouší několik přístupů, než si uvědomí, že žádný z nich skutečně neřeší problém.
"Seřaďte podle data odeslání" - proč to nestačí
Nejčastější návrh je přepnout z řazení podle data "přijetí" na datum "odeslání" v poštovním klientovi. To sice změní pořadí zobrazení, ale neopraví podkladová data. Výsledky vyhledávání stále ukazují špatné datum. Integrace s kalendářem, nástroje pro dodržování předpisů a automatizované pracovní postupy závislé na datu přijetí nadále nefungují. A uživatelé musí pamatovat na změnu tohoto nastavení na každém zařízení a v každé složce.
Opětovná migrace - drahá a riziková
Někteří administrátoři zvažují opětovné spuštění migrace v naději, že se problému s datem při druhém průchodu vyhnou. Tento přístup je drahý (500 až 5 000 EUR podle počtu schránek), časově náročný a rizikový. Druhá migrace způsobí stejný problém s hlavičkou "Received", zdvojnásobí riziko ztráty dat a vyžaduje značný výpadek. Opětovná migrace problém s datem nevyřeší, pokud migrační nástroj nebude zásadně upraven.
Ruční úprava hlaviček - vyžaduje přístup k serveru
Technicky oprava zahrnuje odstranění migrační hlavičky "Received" z každého e-mailu. Ale dělat to ručně vyžaduje přímý přístup k serveru, znalost struktury e-mailových hlaviček a vlastní skriptování. Pro schránku s 10 000 e-maily je ruční úprava nepraktická a nebezpečně náchylná k chybám. E-maily podepsané S/MIME, zprávy šifrované PGP, multipart struktury s vnořenými hranicemi MIME, problémy s Content-Transfer-Encoding, ne-ASCII hlavičky (RFC 2047), nadměrné přílohy: každý z těchto případů může způsobit, že jednoduchý skript nevratně poškodí data. Jak potvrdíte, že 10 000 opravených e-mailů je všech neporušených? To nejde, pokud nemáte ověřovací systém navržený přímo pro tento účel.
Skutečné řešení - obnovení původních dat
Správný přístup spočívá v identifikaci migračních artefaktů v řetězci hlaviček každého e-mailu a aplikaci cílených oprav, které obnoví původní chronologické pořadí ve všech poštovních klientech. Nejde o jednoduchou úpravu hlavičky. Proces zahrnuje validaci souladu s RFC, zachování struktury zprávy a porovnávání signatur migrace z databáze profilů známých nástrojů.
Jak Redate.io řeší tento problém
Redate.io se připojí ke schránce (Google Workspace, Microsoft 365 nebo jakýkoli server IMAP) a analyzuje každý e-mail pro identifikaci zpráv zasažených migračními hlavičkami. Analýza je zdarma a ukáže přesně kolik e-mailů je zasaženo před jakoukoli platbou.
Pro každý zasažený e-mail proprietární opravný engine Redate.io provede zprávu vícestupňovým analytickým pipeline. Engine aplikuje porovnávání signatur na stovkách známých profilů migračních nástrojů, sestavených ze zpracování velkých objemů reálných e-mailových dat. Zvládá problémy s kódováním, multipart struktury, inline přílohy a desítky okrajových případů, které by způsobily poškození dat u DIY skriptu (ne zrovna objev, jaký chcete udělat v pondělí ráno). Každý opravený e-mail projde ověřením integrity před finalizací. Původní zpráva je přesunuta do viditelné složky "Redate.io - Originals" (není smazána) a uchovávána 30 dnů.
Výsledek? E-maily zobrazují svá správná původní data ve všech klientech. Řazení opět funguje. Chronologická historie schránky je obnovena.
Často kladené otázky
Lze data opravit měsíce po migraci?
Ano. Původní hlavička "Date" je zachována uvnitř e-mailové zprávy bez ohledu na to, kdy migrace proběhla. Redate.io dokáže opravit data e-mailů týdny, měsíce nebo dokonce roky po migraci. Oprava funguje, dokud jsou původní hlavičky e-mailu neporušené.
Smaže oprava dat mé e-maily?
Ne. Redate.io nikdy nemaže e-maily. Původní zprávy jsou přesunuty do viditelné složky s názvem "Redate.io - Originals" ve schránce, kde zůstávají přístupné po dobu 30 dnů. Každý opravený e-mail je ověřen oproti originálu před finalizací procesu. Pokud ověření u zprávy selže, originál zůstane nedotčen.
Funguje to se sdílenými schránkami?
Ano. Redate.io funguje se sdílenými schránkami v Google Workspace a Microsoft 365. Pro sdílené schránky je vyžadován přístup na úrovni administrátora k autorizaci připojení. Proces je totožný s individuálními schránkami: analýza, oprava, ověření.
Připraveni obnovit správná data? Spusťte bezplatnou analýzu a zjistěte, kolik e-mailů je zasaženo v každé schránce.