Problem - svi emailovi prikazuju isti datum
Nakon IMAP migracije, korisnici otvore svoj poštanski sandučić 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 kronološki pregled sandučića 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čić. Pristigla pošta, poslane stavke, svaka mapa 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 vremensku oznaku migracije, a ne izvorni datum. Budući da Apple Mail koristi IMAP metapodatke poslužitelja 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 netoč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čić 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 zahtijeva kratak pogled na IMAP protokol i strukturu zaglavlja.
Kako IMAP migracijski alati postupaju sa zaglavljima
Kad se email migrira s jednog poslužitelja na drugi, migracijski alat preuzima izvornu poruku s izvorišnog poslužitelja i učitava je na odredišni poslužitelj putem IMAP APPEND naredbe. Tijekom tog procesa, IMAP protokol zahtijeva od odredišnog poslužitelja da doda zaglavlje "Received" poruci. To zaglavlje sadrži vremensku oznaku trenutka kad je poruka umetnuta u novi poslužitelj, 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 poslužitelja 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 vremenskom oznakom 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 slijede 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 poslužitelji pohranjuju dvije različite vrijednosti datuma za svaku poruku. Zaglavlje "Date" dio je same email poruke i bilježi kad je poruka izvorno napisana i poslana. INTERNALDATE je metapodatak koji pohranjuje IMAP poslužitelj, a predstavlja kad je poruka isporučena ili umetnuta u taj konkretni poslužitelj.
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 ispravak 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 ispravak CloudM datuma u Gmailu, Outlooku, Google Workspaceu i Microsoft 365.
imapsync
imapsync je popularan open source alat među Linux administratorima i hosting tvrtkama. Iako imapsync pokušava sačuvati INTERNALDATE, odredišni poslužitelj svejedno dodaje zaglavlje "Received" tijekom APPEND operacije. FAQ imapsynca priznaje ovo ograničenje, ali ne nudi ugrađeno rješenje za uklanjanje dodanog zaglavlja nakon migracije. Pogledajte vodiče za ispravak 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 ispravak GSMMO datuma u Outlooku, Gmailu i Apple Mailu.
Exchange Admin Center (izvorni IMAP uvoz)
Microsoftov Exchange Admin Center uključuje značajku 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 ispravak datuma Exchange IMAP migracije u Outlooku i OWA.
Ručno IMAP kopiranje
Čak i ručno kopiranje emailova između IMAP poslužitelja putem klijenta poput Thunderbirda može proizvesti ovaj problem s datumima. Kad klijent elektroničke pošte kopira poruku putem IMAP-a, odredišni poslužitelj je tretira kao novo umetanje i dodaje vlastito zaglavlje "Received" s trenutnom vremenskom oznakom. Pogledajte vodiče za ispravak datuma ručnog IMAP kopiranja u Outlooku, Gmailu, Thunderbirdu i Apple Mailu.
Zašto uobičajena zaobilazna rješenja ne funkcioniraju
Suočeni s ovim problemom, korisnici i administratori obično pokušavaju nekoliko pristupa prije nego shvate da nijedan ne rješava pravi problem.
"Sortirajte po datumu slanja" - zašto to nije dovoljno
Najčešći savjet je prebacivanje s sortiranja po datumu "primitka" na datum "slanja" u klijentu elektroničke pošte. To doista mijenja redoslijed prikaza, ali ne ispravlja temeljne podatke. Rezultati pretraživanja 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 mapi.
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čića), dugotrajan i rizičan. Druga migracija uvodi isti problem zaglavlja "Received", udvostručuje rizik gubitka podataka i zahtijeva značajan prekid rada. Ponovna migracija ne rješava problem datuma osim ako migracijski alat nije temeljito izmijenjen.
Ručno uređivanje zaglavlja - zahtijeva pristup poslužitelju
Tehnički, ispravak uključuje uklanjanje migracijskog zaglavlja "Received" iz svakog emaila. No ručno to raditi zahtijeva izravan pristup poslužitelju, poznavanje strukture zaglavlja emaila i prilagođeno skriptiranje. Za sandučić s 10.000 emailova, ručno uređivanje je nepraktično i opasno podložno pogreš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 privici, 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 rješenje - obnova izvornih datuma
Ispravan pristup je identificirati migracijske artefakte u lancu zaglavlja svakog emaila i primijeniti ciljane ispravke koji obnavljaju izvorni kronološ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 usporedbu potpisa migracije iz baze podataka poznatih profila alata.
Kako Redate.io ispravlja ovaj problem
Redate.io se spaja na poštanski sandučić (Google Workspace, Microsoft 365 ili bilo koji IMAP poslužitelj) i analizira svaki email kako bi identificirao poruke pogođene migracijskim zaglavljima. Analiza je besplatna i prikazuje toč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 cjevovod. Mehanizam primjenjuje usporedbu potpisa na stotinama poznatih profila migracijskih alata, izgrađenih obradom velikih količina stvarnih email podataka. Rješava probleme kodiranja, multipart strukture, umetnute privitke 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 cjelovitosti prije finalizacije. Izvorna poruka premjesti se u vidljivu mapu "Redate.io - Originals" (ne briše se) i čuva 30 dana.
Rezultat? Emailovi prikazuju svoje izvorne ispravne datume u svim klijentima. Sortiranje ponovno funkcionira. Kronološki pregled sandučića je obnovljen.
Česta pitanja
Mogu li se datumi ispraviti mjesecima 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 tjednima, mjesecima ili čak godinama nakon migracije. Ispravak funkcionira sve dok su izvorna zaglavlja emaila netaknuta.
Hoće li ispravak datuma izbrisati moje emailove?
Ne. Redate.io nikad ne briše emailove. Izvorne poruke premještaju se u vidljivu mapu pod nazivom "Redate.io - Originals" unutar sandučića, 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.
Funkcionira li to s dijeljenim sandučićima?
Da. Redate.io funkcionira s dijeljenim sandučićima u Google Workspaceu i Microsoft 365. Za dijeljene sandučiće, potreban je pristup na razini administratora za autorizaciju spajanja. Proces je identičan kao za pojedinačne sandučiće: analiza, ispravak, provjera.
Želite obnoviti ispravne datume? Pokrenite besplatnu analizu i saznajte koliko je emailova pogođeno u svakom sandučiću.