Problem - svi emailovi prikazuju isti datum
Nakon IMAP migracije, korisnici otvore svoj poštanski sanduče i ugledaju zabrinjavajući prizor: svaki email prikazuje potpuno isti datum. Umjesto izvornog datuma slanja ili primitka, sve poruke nose datum na koji je migracija provedena. Godina korespondencije koja izgleda kao da je stigla istog dana.
Za IT administratore, ovo je noćna mora. Zahtjevi za podršku pristižu lavinski, korisnici više ne mogu ništa pronaći po datumu, a hronološki pregled sandučadi je u praksi uništen.
Kako to izgleda u Outlooku
U Microsoft Outlooku, stupac "Primljeno" prikazuje datum migracije za svaki email. Bez obzira je li poruka poslana 2018. ili 2023. godine, Outlook prikazuje isti datum, onaj kad je migracijski alat obradio sanduče. Pristigla pošta, poslane stavke, svaka folder je pogođena. Korisnici koji se oslanjaju na sortiranje po datumu nalaze da im je radni tijek potpuno poremećen.
Kako to izgleda u Apple Mailu
Apple Mail na macOS-u i iOS-u ponaša se slično. Datum prikazan pokraj svake poruke odražava vremenski pečat migracije, a ne izvorni datum. Budući da Apple Mail koristi IMAP metapodatke servera za određivanje datuma prikaza, isti temeljni problem proizvodi isti vidljivi rezultat. Pregledavajući pristiglu poštu, korisnik vidi samo zid identičnih datuma.
Kako to izgleda u Gmailu (web sučelje)
Gmail web sučelje predstavlja nešto drugačiju situaciju. Gmail web klijent općenito koristi zaglavlje "Date" samog emaila, pa se poruke mogu pojaviti s ispravnim datumom u Gmailu. Ali IMAP INTERNALDATE ostaje netačan, što znači da će svaki IMAP klijent koji se spoji na taj Gmail račun (Outlook, Thunderbird, Apple Mail) prikazati datum migracije. Dakle, isti sanduče izgleda ispravno u jednom klijentu, a neispravno u drugom. Zapravo prilično zbunjujuće.
Zašto se to događa - tehnički uzrok
Temeljni uzrok leži u načinu na koji IMAP migracijski alati postupaju sa zaglavljima emaila i u načinu na koji klijenti elektroničke pošte određuju koji datum prikazati. Razumijevanje ovoga zahteva kratak pogled na IMAP protokol i strukturu zaglavlja.
Kako IMAP migracijski alati postupaju sa zaglavljima
Kad se email migrira s jednog servera na drugi, migracijski alat preuzima izvornu poruku s izvorišnog servera i učitava je na odredišni server putem IMAP APPEND naredbe. Tijekom tog procesa, IMAP protokol zahteva od odredišnog servera da doda zaglavlje "Received" poruci. To zaglavlje sadrži vremenski pečat trenutka kad je poruka umetnuta u novi server, odnosno datum migracije.
Zaglavlje "Received" koje kvari sve
Email poruke obično sadrže više zaglavlja "Received", od kojih je svako dodano od strane servera koji je obrađivao poruku tijekom izvorne isporuke. Klijenti poput Outlooka određuju "datum primitka" čitajući najnovije zaglavlje "Received", ono na vrhu lanca. Kad migracijski alat doda novo zaglavlje "Received" s vremenskim pečatom migracije, ono postaje najnovije, i klijenti elektroničke pošte prikazuju taj datum umjesto izvornog.
Ovo nije greška migracijskog alata niti klijenta elektroničke pošte. Oba ispravno slede IMAP i email standarde. Problem je u tome što ti standardi nikad nisu bili dizajnirani za masovnu migraciju, a interakcija između IMAP APPEND-a i logike prikaza datuma proizvodi ovaj neželjeni rezultat.
INTERNALDATE nasuprot zaglavlju Date
IMAP serveri pohranjuju dvije različite vrednosti datuma za svaku poruku. Zaglavlje "Date" dio je same email poruke i beleži kad je poruka izvorno napisana i poslana. INTERNALDATE je metapodatak koji pohranjuje IMAP server, a predstavlja kad je poruka isporučena ili umetnuta u taj konkretni server.
Neki migracijski alati pokušavaju sačuvati izvorni INTERNALDATE postavljajući ga tijekom APPEND naredbe. No čak i kad je INTERNALDATE ispravno postavljen, dodano zaglavlje "Received" i dalje uzrokuje probleme u klijentima koji daju prednost datumu "Received" nad INTERNALDATE-om.
Koji migracijski alati uzrokuju ovaj problem?
Gotovo svi IMAP migracijski alati mogu izazvati ovaj problem. Problem je svojstven IMAP protokolu, a ne specifičan za neki alat. Ipak, neki se češće povezuju s problemom zbog svoje raširene uporabe.
BitTitan MigrationWiz
BitTitan MigrationWiz jedan je od najpopularnijih komercijalnih migracijskih alata koje koriste MSP-ovi i IT konzultanti. MigrationWiz dodaje zaglavlje "Received" koje sadrži "mx.migrationwiz.com" tijekom procesa migracije. Ovo zaglavlje postaje najnovije u lancu, uzrokujući prikaz datuma migracije u Outlooku i drugim IMAP klijentima. Pogledajte detaljne vodiče za ispravka BitTitan datuma u Outlooku, Microsoft 365, Google Workspace i Exchange Online.
CloudM Migrate
CloudM Migrate (ranije Cloud Migrator) naširoko se koristi za migracije na Google Workspace. Kao i drugi alati, CloudM dodaje vlastito zaglavlje "Received" pri IMAP umetanju. Emailovi migrirani pomoću CloudM-a prikazuju datum migracije u klijentima koji se oslanjaju na zaglavlje "Received". Pogledajte vodiče za ispravka CloudM datuma u Gmailu, Outlooku, Google Workspaceu i Microsoft 365.
imapsync
imapsync je popularan open source alat među Linux administratorima i hosting kompanijama. Iako imapsync pokušava sačuvati INTERNALDATE, odredišni server svejedno dodaje zaglavlje "Received" tijekom APPEND operacije. FAQ imapsynca priznaje ovo ograničenje, ali ne nudi ugrađeno rešenje za uklanjanje dodanog zaglavlja nakon migracije. Pogledajte vodiče za ispravka imapsync datuma u Outlooku, Gmailu, Microsoft 365 i Google Workspaceu.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) Googleov je vlastiti alat za migraciju s Exchangea ili iz Outlook PST datoteka na Google Workspace. GSMMO može proizvesti isti problem s datumima, posebno kad migracija uključuje posredni IMAP korak. Pogledajte vodiče za ispravka GSMMO datuma u Outlooku, Gmailu i Apple Mailu.
Exchange Admin Center (izvorni IMAP uvoz)
Microsoftov Exchange Admin Center uključuje funkciju izvornog IMAP uvoza za migraciju na Exchange Online (Microsoft 365). Ovaj ugrađeni migracijski alat dodaje zaglavlja "Received" tijekom uvoza, uzrokujući isti problem prikaza datuma. Pogledajte vodiče za ispravka datuma Exchange IMAP migracije u Outlooku i OWA.
Ručno IMAP kopiranje
Čak i ručno kopiranje emailova između IMAP servera putem klijenta poput Thunderbirda može proizvesti ovaj problem s datumima. Kad klijent elektroničke pošte kopira poruku putem IMAP-a, odredišni server je tretira kao novo umetanje i dodaje vlastito zaglavlje "Received" s trenutnom vremenskim pečatom. Pogledajte vodiče za ispravka datuma ručnog IMAP kopiranja u Outlooku, Gmailu, Thunderbirdu i Apple Mailu.
Zašto uobičajena zaobilazna rešenja ne funkcionišu
Suočeni s ovim problemom, korisnici i administratori obično pokušavaju nekoliko pristupa prije nego shvate da nijedan ne rešava pravi problem.
"Sortirajte po datumu slanja" - zašto to nije dovoljno
Najčešći savet je prebacivanje s sortiranja po datumu "primitka" na datum "slanja" u klijentu elektroničke pošte. To doista mijenja redosled prikaza, ali ne ispravlja temeljne podatke. Rezultati pretrage i dalje prikazuju krivi datum. Kalendarske integracije, alati za usklađenost i automatizirani radni tijekovi koji ovise o datumu primitka nastavljaju neispravan rad. A korisnici moraju pamtiti da promijene tu postavku na svakom uređaju i u svakoj folderu.
Ponovna migracija - skupa i rizična
Neki administratori razmatraju ponovnu migraciju, nadajući se da će izbjeći problem s datumima u drugom pokušaju. Ovaj pristup je skup (500 do 5.000 EUR ovisno o broju sandučadi), dugotrajan i rizičan. Druga migracija uvodi isti problem zaglavlja "Received", udvostručuje rizik gubitka podataka i zahteva značajan prekid rada. Ponovna migracija ne rešava problem datuma osim ako migracijski alat nije temeljito izmijenjen.
Ručno uređivanje zaglavlja - zahteva pristup serveru
Tehnički, ispravka uključuje uklanjanje migracijskog zaglavlja "Received" iz svakog emaila. No ručno to raditi zahteva izravan pristup serveru, poznavanje strukture zaglavlja emaila i prilagođeno skriptiranje. Za sanduče s 10.000 emailova, ručno uređivanje je nepraktično i opasno podložno greškama. S/MIME potpisani emailovi, PGP šifrirane poruke, multipart strukture s ugniježđenim MIME granicama, problemi s Content-Transfer-Encoding-om, ne-ASCII zaglavlja (RFC 2047), preveliki prilozi, oštećene MIME granice - svaki od tih slučajeva može dovesti do toga da osnovna skripta nepovratno ošteti podatke. Kako potvrditi da je svih 10.000 ispravljenih emailova netaknuto? Ne može se, osim sa sustavom provjere dizajniranim upravo za to.
Pravo rešenje - obnova izvornih datuma
Ispravan pristup je identificirati migracijske artefakte u lancu zaglavlja svakog emaila i primijeniti ciljane ispravke koji obnavljaju izvorni hronološki poredak u svim klijentima elektroničke pošte. Ovo nije jednostavno uređivanje zaglavlja. Proces uključuje validaciju usklađenosti s RFC standardima, očuvanje strukture poruke i poređenju potpisa migracije iz baze podataka poznatih profila alata.
Kako Redate.io ispravlja ovaj problem
Redate.io se spaja na poštanski sanduče (Google Workspace, Microsoft 365 ili bilo koji IMAP server) i analizira svaki email kako bi identificirao poruke pogođene migracijskim zaglavljima. Analiza je besplatna i prikazuje tačno koliko je emailova pogođeno prije bilo kakve naplate.
Za svaki pogođeni email, vlasnički mehanizam za ispravke u Redate.io provodi poruku kroz višestupanjski analitički cevovod. Mehanizam primjenjuje poređenju potpisa na stotinama poznatih profila migracijskih alata, izgrađenih obradom velikih količina stvarnih email podataka. Rješava probleme kodiranja, multipart strukture, umetnute priloge i desete rubnih slučajeva koji bi doveli do toga da DIY skripta ošteti podatke (ne baš otkriće koje biste željeli u ponedjeljak ujutro). Svaki ispravljeni email prolazi provjeru celovitosti prije finalizacije. Izvorna poruka premjesti se u vidljivu folder "Redate.io - Originals" (ne briše se) i čuva 30 dana.
Rezultat? Emailovi prikazuju svoje izvorne ispravne datume u svim klijentima. Sortiranje ponovno funkcioniše. Kronološki pregled sandučadi je obnovljen.
Česta pitanja
Mogu li se datumi ispraviti mesecima nakon migracije?
Da. Izvorno zaglavlje "Date" sačuvano je unutar email poruke neovisno o tome kad je migracija provedena. Redate.io može ispraviti datume emailova nedeljama, mesecima ili čak godinama nakon migracije. Ispravak funkcioniše sve dok su izvorna zaglavlja emaila netaknuta.
Hoće li ispravka datuma izbrisati moje emailove?
Ne. Redate.io nikad ne briše emailove. Izvorne poruke premještaju se u vidljivu folder pod nazivom "Redate.io - Originals" unutar sandučadi, gdje ostaju dostupne 30 dana. Svaki ispravljeni email provjerava se u odnosu na izvornik prije finalizacije procesa. Ako provjera ne uspije za neku poruku, izvornik ostaje netaknut.
Funkcioniše li to s deljenim sandučeima?
Da. Redate.io funkcioniše s deljenim sandučeima u Google Workspaceu i Microsoft 365. Za deljene sandučee, potreban je pristup na razini administratora za autorizaciju spajanja. Proces je identičan kao za pojedinačne sandučee: analiza, ispravka, provjera.
Želite obnoviti ispravne datume? Pokrenite besplatnu analizu i saznajte koliko je emailova pogođeno u svakom sandučeu.