Problem - vsetky emaily zobrazuju rovnaky datum
Po IMAP migracii pouzivatelia otvoria svoju postovu schranku a objavia znepokojujuci stav: kazdy email zobrazuje presne ten isty datum. Namiesto povodneho datumu odoslania alebo prijatia vsetky spravy nesie datum, kedy bola migracia vykonana. Roky korespodencie, ktore vyzera, ze prisli v ten isty den.
Pre IT administratorov je to nocna mora. Tikety sa hromadia, pouzivatelia nevedia nic najst podla datumu a chronologicka historia postovej schranky je v praxi znicena.
Ako to vyzera v Outlooku
V Microsoft Outlooku stlpec "Prijate" zobrazuje datum migracie pri kazdom emaili. Ci bola sprava odoslana v roku 2018 alebo 2023, Outlook ukazuje ten isty datum, den kedy migracny nastroj spracoval postovu schranku. Dorucena posta, odoslane polozky, kazdy priecinok je postihnuty. Pouzivatelia, ktori sa spolieha na triedenie podla datumu, maju pracovny postup uplne naruseny.
Ako to vyzera v Apple Mail
Apple Mail na macOS a iOS sa sprava podobne. Zobrazeny datum pri kazdej sprave odraaza casovu peciatku migracie namiesto povodneho datumu. Kedze Apple Mail vyuziva metaudaje IMAP servera na urcenie zobrazovanych datumov, ten isty zakladny problem produkuje ten isty viditelny vysledok. Pri prehliadani dorucenej posty vidite len stenu rovnakych datumov.
Ako to vyzera v Gmail (webove rozhranie)
Webove rozhranie Gmailu predstavuje mierne odlisnu situaciu. Webovy klient Gmailu zvycajne pouziva hlavicku "Date" zo samotneho emailu, takze spravy sa mozu zobrazit so spravnym datumom v Gmaili. Ale IMAP INTERNALDATE zostava nespravna, co znamena, ze kazdy IMAP klient pripojeny k tomuto Gmail uctu (Outlook, Thunderbird, Apple Mail) zobrazi datum migracie. Takze ta ista postova schranka vyzera spravne v jednom klientovi, ale nespravne v inom. Vlastne dost matuce.
Preco sa to deje - technicka pricina
Hlavna pricina spociva v tom, ako migracne nastroje IMAP spracovavaju hlavicky emailov a ako emailovi klienti urcuju, ktory datum zobrazit. Pochopenie tohto vyzaduje kratky pohlad na protokol IMAP a strukturu hlaviciek.
Ako migracne nastroje IMAP spracovavaju hlavicky
Ked sa email migruje z jedneho servera na druhy, migracny nastroj stiahne surovu spravu zo zdrojoveho servera a nahra ju na cielovy server pomocou prikazu IMAP APPEND. Pocas tohto procesu protokol IMAP vyzaduje, aby cielovy server pridal k sprave hlavicku "Received". Tato hlavicka obsahuje casovu peciatku momentu vlozenia spravy do noveho servera, teda datum migracie.
Hlavicka "Received", ktora rozbije vsetko
Emailove spravy zvycajne obsahuju viacero hlaviciek "Received", kazda pridana postovym serverom, ktory spravu spracoval pocas jej povodneho dorucenia. Klienti ako Outlook urcuju "datum prijatia" citanim najnovsej hlavicky "Received", tej na vrchu retazca. Ked migracny nastroj prida novu hlavicku "Received" s casovou peciatkou migracie, stane sa najnovsou a emailoví klienti zobrazia tento datum namiesto povodneho.
Nejde o chybu migracneho nastroja ani emailoveho klienta. Oba spravne dodrziavaju standardy IMAP a emailov. Problem je v tom, ze tieto standardy nikdy neboli navrhnuté pre hromadnu migraciu a interakcia medzi IMAP APPEND a logikou zobrazovania datumov produkuje tento neziadany vysledok.
INTERNALDATE vs hlavicka Date
IMAP servery uchovavaju dve rozne hodnoty datumu pre kazdu spravu. Hlavicka "Date" je sucastou samotnej emailovej spravy, zaznamenava, kedy bola sprava povodne napisana a odoslana. INTERNALDATE su metaudaje uchovavane IMAP serverom, reprezentujuce kedy bola sprava dorucena alebo vlozena na tento konkretny server.
Niektore migracne nastroje sa pokusaju zachovat povodnu INTERNALDATE jej nastavenim pocas prikazu APPEND. Ale aj ked je INTERNALDATE spravne nastavena, pridana hlavicka "Received" stale sposobuje problemy v klientoch, ktori uprednostnuju datum "Received" pred INTERNALDATE.
Ktore migracne nastroje sposobuju tento problem?
Takmer kazdy migracny nastroj IMAP moze sposobit tento problem. Problem je inherentny protokolu IMAP, nie specificky pre konkretny nastroj. Niektore su vsak castejsie spojenés problemom kvoli ich sirokemu pouzivaniu.
BitTitan MigrationWiz
BitTitan MigrationWiz je jedným z najpopularnejsich komercnych migracnych nastrojov pouzivanych MSP a IT konzultantmi. MigrationWiz pridava hlavicku "Received" obsahujucu "mx.migrationwiz.com" pocas migracneho procesu. Tato hlavicka sa stava najnovsou v retazci, co sposobuje zobrazenie datumu migracie v Outlooku a inych IMAP klientoch. Pozrite si podrobne navody na opravu datumov BitTitan v Outlooku, Microsoft 365, Google Workspace a Exchange Online.
CloudM Migrate
CloudM Migrate (predtym Cloud Migrator) je siroko pouzivany pri migraciach na Google Workspace. Rovnako ako ine nastroje, aj CloudM pridava svoju vlastnu hlavicku "Received" pocas IMAP inserovania. Emaily migrovane cez CloudM zobrazuju datum migracie v klientoch, ktori sa spoliehaju na hlavicku "Received". Pozrite si navody na opravu datumov CloudM v Gmaili, Outlooku, Google Workspace a Microsoft 365.
imapsync
imapsync je open-source nastroj popularny medzi Linux administratormi a hostingovymi poskytovatelmi. Hoci sa imapsync pokusa zachovat INTERNALDATE, cielovy server stale pridava hlavicku "Received" pocas operacie APPEND. FAQ imapsync toto obmedzenie uznava, ale neponuka vstavane riesenie na odstranenie pridanej hlavicky po migracii. Pozrite si navody na opravu datumov imapsync v Outlooku, Gmaili, Microsoft 365 a Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) je vlastny nastroj Googlu na migraciu z Exchange alebo suborov PST Outlooku do Google Workspace. GSMMO moze sposobit ten isty problem s datumom, najma ked migracia zahrna medzilahlý IMAP krok. Pozrite si navody na opravu datumov GSMMO v Outlooku, Gmaili a Apple Mail.
Exchange Admin Center (nativny IMAP import)
Centrum spravy Exchange od Microsoftu zahrna nativnu funkciu importu IMAP na migraciu do Exchange Online (Microsoft 365). Tento vstavaný migracny nastroj pridava hlavicky "Received" pocas importu, co sposobuje rovnaky problem so zobrazenim datumov. Pozrite si navody na opravu datumov migracie Exchange IMAP v Outlooku a OWA.
Manualne kopirovanie IMAP
Dokonca aj manualne kopirovanie emailov medzi IMAP servermi cez klienta ako Thunderbird moze sposobit tento problem s datumom. Ked emailovy klient kopiruje spravu cez IMAP, cielovy server ju spracuje ako nove vlozenie a prida svoju vlastnu hlavicku "Received" s aktualnou casovou peciatkou. Pozrite si navody na opravu datumov manualneho IMAP kopirovania v Outlooku, Gmaili, Thunderbirde a Apple Mail.
Preco bezne obchadzkove riesenia nefunguju
Tvareni tomuto problemu pouzivatelia aj administratori zvycajne skusia niekolko pristupov, nez si uvedomia, ze ziadny skutocne problem neriesi.
"Triedte podla datumu odoslania" - preco to nestaci
Najcastejsi navrh je prepnut triedenie z datumu "prijatia" na datum "odoslania" v emailovom klientovi. To sice zmeni poradie zobrazovania, ale neopraví zakladne udaje. Vysledky vyhladavania stale ukazuju nespravny datum. Integracia s kalendarom, nastroje na dodrzovanie predpisov a automatizovane pracovne postupy zavisiacé od datumu prijatia nadalej nefunguju spravne. A pouzivatelia musia mysliet na zmenu tohto nastavenia na kazdom zariadeni a v kazdom priecinku.
Opakovana migracia - nakladna a riziková
Niektori administratori zvazia zopakovanie migracie v nadeji, ze sa problemu s datumom druhy raz vyhnu. Tento pristup je nakladny (500 az 5 000 EUR podla poctu schranok), casovo narocny a riskantny. Druha migracia prinasa ten isty problem s hlavickou "Received", zdvojnásobuje riziko straty udajov a vyzaduje vyznamny vypadok. Opakovana migracia problem s datumom neriesi, pokial nie je migracny nastroj zasadne zmeneny.
Manualna uprava hlaviciek - vyzaduje pristup k serveru
Technicky korekcia zahrnuje odstranenie migracnej hlavicky "Received" z kazdeho emailu. Ale robit to manualne vyzaduje priamy pristup k serveru, znalost struktury emailových hlaviciek a vlastny skript. Pri schranke s 10 000 emailmi je manualna uprava neprakticka a nebezpecne nachylna na chyby. Emaily s podpismi S/MIME, sifrovane spravy PGP, multipart struktury s vnorenym MIME hranicami, problemy s Content-Transfer-Encoding, hlavicky s non-ASCII znakmi (RFC 2047), prilis velke prilohy: kazdy z tychto pripadov moze sposobit, ze zakladný skript nevratne poskodi udaje. Ako potvrdite, ze 10 000 opravenych emailov je vsetkych neporúsenych? Nedá sa, ibaže s overovacim systemom navrhnutym specificky na tento ucel.
Skutocne riesenie - obnovenie povodnych datumov
Spravny pristup spociva v identifikacii migracnych artefaktov v retazci hlaviciek kazdeho emailu a aplikovani cielenych korekci, ktore obnovia povodne chronologicke zoradenie vo vsetkych emailovych klientoch. Nejde o jednoduchu upravu hlaviciek. Proces zahrna validaciu suladnosti s RFC, zachovanie struktury spravy a porovnavanie podpisov migracie z databazy znamych profilov nastrojov.
Ako Redate.io opravuje tento problem
Redate.io sa pripoji k postovej schranke (Google Workspace, Microsoft 365 alebo akykolvek IMAP server) a analyzuje kazdy email na identifikaciu sprav postihnutych migracnymi hlavickami. Analyza je bezplatna a ukazuje presne, kolko emailov je postihnutych, este pred akymkolvek platenim.
Pre kazdy postihnuty email proprietarny korekčny motor Redate.io spracuje spravu cez viacstupnovy analyticly pipeline. Motor aplikuje porovnavanie podpisov na stovkach znamych profilov migracnych nastrojov, vytvorenych zo spracovania velkych objemov realnych emailovych udajov. Riesi problemy s kodovanim, multipart struktury, inline prilohy a desiatky okrajových pripadov, ktore by sposobili, ze DIY skript poskodiudaje (nie ten typ zistenia, ktory chcete v pondelok rano). Kazdy opraveny email prechádza kontrolou integrity pred finalizaciou. Povodna sprava sa presunie do viditelneho priecinka "Redate.io - Originals" (nie je zmazana) a uchovava sa 30 dni.
Vysledok? Emaily zobrazuju svoje spravne povodne datumy vo vsetkych klientoch. Triedenie opat funguje. Chronologicka historia postovej schranky je obnovena.
Casto kladene otazky
Daju sa datumy opravit mesiace po migracii?
Ano. Povodna hlavicka "Date" sa uchovava vo vnutri emailovej spravy nezavisle od toho, kedy migracia prebehla. Redate.io dokaze opravit datumy emailov tyzdne, mesiace alebo dokonca roky po migracii. Korekcia funguje, pokial su povodne hlavicky emailu neporusene.
Zmaze korekcia datumov moje emaily?
Nie. Redate.io nikdy nemaze emaily. Povodne spravy sa presunu do viditelneho priecinka s nazvom "Redate.io - Originals" v postovej schranke, kde zostanu pristupne 30 dni. Kazdy opraveny email sa overuje oproti originalu pred finalizaciou procesu. Ak overenie pre nejaku spravu zlyha, original zostane nedotknuty.
Funguje to so zdielanymi postovymi schrankami?
Ano. Redate.io funguje so zdielanymi postovými schrankami v Google Workspace a Microsoft 365. Pre zdielane schranky je potrebny pristup na urovni administratora na autorizaciu pripojenia. Proces je identicky ako pri individualnych schrankach: analyza, korekcia, overenie.
Ste pripraveni obnovit spravne datumy? Spustite bezplatnu analyzu a zistite, kolko emailov je postihnutych v kazdej postovej schranke.