Tezava - vsa e-posta prikazuje isti datum
Po IMAP selitvi uporabniki odprejo svoj postni predal in odkrijejo zaskrbljujoc prizor: vsako e-postno sporocilo prikazuje tocno isti datum. Namesto izvirnega datuma posiljanja ali prejema vsa sporocila nosijo datum, ko je bila selitev izvedena. Leta dopisovanja, ki izgledajo, kot da so prispela na isti dan.
Za IT skrbnike je to nocna mora. Zahtevki se kopicijo, uporabniki ne najdejo nicesar po datumu in kronoloski zapis postnega predala je v praksi unicen.
Kako izgleda v Outlooku
V Microsoft Outlooku stolpec "Prejeto" prikazuje datum selitve za vsako e-postno sporocilo. Ne glede na to, ali je bilo sporocilo poslano leta 2018 ali 2023, Outlook prikazuje isti datum, dan ko je selitveno orodje obdelalo postni predal. Prejeta posta, poslani predmeti, vsaka mapa je prizadeta. Uporabniki, ki se zanasajo na razvrscanje po datumu, imajo delovni tok popolnoma prekinjen.
Kako izgleda v Apple Mail
Apple Mail na macOS in iOS se obnasa podobno. Prikazani datum ob vsakem sporocilu odrazha casovni zig selitve namesto izvirnega datuma. Ker Apple Mail uporablja metapodatke IMAP streznika za dolocanje prikazanih datumov, ista osnovna tezava povzroci isti vidni rezultat. Pri pregledovanju prejete poste vidite samo steno enakih datumov.
Kako izgleda v Gmail (spletni vmesnik)
Spletni vmesnik Gmail predstavlja rahlo drugacno situacijo. Gmailov spletni odjemalec obicajno uporabi glavo "Date" iz samega e-postnega sporocila, zato se sporocila lahko prikazejo s pravilnim datumom v Gmailu. Toda IMAP INTERNALDATE ostane napacen, kar pomeni, da bo vsak IMAP odjemalec, povezan s tem Gmail racunom (Outlook, Thunderbird, Apple Mail), prikazal datum selitve. Pravzaprav precej zmedeno, ko isti postni predal izgleda pravilno v enem odjemalcu, a napacno v drugem.
Zakaj se to dogaja - tehnicni vzrok
Temeljni vzrok je v tem, kako IMAP selitvena orodja obravnavajo glave e-postnih sporocil in kako e-postni odjemalci dolocajo, kateri datum prikazati. Razumevanje tega zahteva kratek vpogled v protokol IMAP in strukturo glav.
Kako IMAP selitvena orodja obravnavajo glave
Ko se e-postno sporocilo seli z enega streznika na drugega, selitveno orodje prenese surovo sporocilo z izvornega streznika in ga nalozi na ciljni streznik s pomocjo ukaza IMAP APPEND. Med tem procesom protokol IMAP zahteva, da ciljni streznik doda glavo "Received" sporocilu. Ta glava vsebuje casovni zig trenutka, ko je bilo sporocilo vstavljeno v novi streznik, torej datum selitve.
Glava "Received", ki pokvari vse
E-postna sporocila obicajno vsebujejo vec glav "Received", vsako doda postni streznik, ki je sporocilo obdelal med izvirno dostavo. Odjemalci kot Outlook dolocajo "datum prejema" z branjem najnovejse glave "Received", tiste na vrhu verige. Ko selitveno orodje doda novo glavo "Received" s casovnim zigom selitve, ta postane najnovejsa in e-postni odjemalci prikazejo ta datum namesto izvirnega.
To ni napaka selitvenega orodja ali e-postnega odjemalca. Oba pravilno upostevata standarde IMAP in e-poste. Tezava je v tem, da ti standardi nikoli niso bili zasnovani za mnozicno selitev in interakcija med IMAP APPEND in logiko prikazovanja datumov povzroci ta nezelen rezultat.
INTERNALDATE proti glavi Date
IMAP strezniki hranijo dve razlicni datumski vrednosti za vsako sporocilo. Glava "Date" je del samega e-postnega sporocila, zapisuje, kdaj je bilo sporocilo prvotno sestavljeno in poslano. INTERNALDATE so metapodatki, ki jih hrani IMAP streznik, predstavljajo, kdaj je bilo sporocilo dostavljeno ali vstavljeno na ta dolocen streznik.
Nekatera selitvena orodja poizkusajo ohraniti izvirni INTERNALDATE z nastavitvijo med ukazom APPEND. Toda tudi ko je INTERNALDATE pravilno nastavljen, dodana glava "Received" se vedno povzroca tezave v odjemalcih, ki dajejo prednost datumu "Received" pred INTERNALDATE.
Katera selitvena orodja povzrocajo to tezavo?
Skoraj vsako IMAP selitveno orodje lahko povzroci to tezavo. Tezava je lastna protokolu IMAP, ne specificna za doloceno orodje. Nekatera so pa pogosteje povezana s tezavo zaradi siroke uporabe.
BitTitan MigrationWiz
BitTitan MigrationWiz je eno izmed najbolj priljubljenih komercialnih selitvenih orodij, ki jih uporabljajo MSP in IT svetovalci. MigrationWiz doda glavo "Received" z "mx.migrationwiz.com" med selitvenim procesom. Ta glava postane najnovejsa v verigi, kar povzroci prikaz datuma selitve v Outlooku in drugih IMAP odjemalcih. Oglejte si podrobne vodnike za popravek datumov BitTitan v Outlooku, Microsoft 365, Google Workspace in Exchange Online.
CloudM Migrate
CloudM Migrate (prej Cloud Migrator) je siroko uporabljan za selitve Google Workspace. Kot druga orodja tudi CloudM doda svojo glavo "Received" med IMAP vstavljanjem. E-posta, seljena s CloudM, prikazuje datum selitve v odjemalcih, ki se zanasajo na glavo "Received". Oglejte si vodnike za popravek datumov CloudM v Gmailu, Outlooku, Google Workspace in Microsoft 365.
imapsync
imapsync je odprtokodno orodje, priljubljeno med Linux skrbniki in ponudniki gostovanja. Ceprav imapsync poizkusa ohraniti INTERNALDATE, ciljni streznik se vedno doda glavo "Received" med operacijo APPEND. FAQ imapsync prizna to omejitev, toda ne ponuja vgrajene resitve za odstranitev dodane glave po selitvi. Oglejte si vodnike za popravek datumov imapsync v Outlooku, Gmailu, Microsoft 365 in Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) je Googlovo lastno orodje za selitev iz Exchange ali Outlookovih PST datotek v Google Workspace. GSMMO lahko povzroci isto datumsko tezavo, zlasti ko selitev vkljucuje vmesni IMAP korak. Oglejte si vodnike za popravek datumov GSMMO v Outlooku, Gmailu in Apple Mail.
Exchange Admin Center (izvorni IMAP uvoz)
Microsoftov Exchange Admin Center vkljucuje izvorno funkcijo IMAP uvoza za selitev v Exchange Online (Microsoft 365). To vgrajeno selitveno orodje doda glave "Received" med uvozom, kar povzroci isto tezavo s prikazom datumov. Oglejte si vodnike za popravek datumov IMAP selitve Exchange v Outlooku in OWA.
Rocno IMAP kopiranje
Tudi rocno kopiranje e-poste med IMAP strezniki prek odjemalca kot Thunderbird lahko povzroci to datumsko tezavo. Ko e-postni odjemalec kopira sporocilo prek IMAP, ga ciljni streznik obravnava kot novo vstavljanje in doda svojo glavo "Received" s trenutnim casovnim zigom. Oglejte si vodnike za popravek datumov rocnega IMAP kopiranja v Outlooku, Gmailu, Thunderbirdu in Apple Mail.
Zakaj obicajne zasilne resitve ne delujejo
Ob soocenju s to tezavo uporabniki in skrbniki obicajno preizkusijo vec pristopov, preden spoznajo, da noben dejansko ne resi tezave.
"Razvrstite po datumu posiljanja" - zakaj to ni dovolj
Najpogostejsi predlog je preklopiti razvrscanje z datuma "prejema" na datum "posiljanja" v e-postnem odjemalcu. To sicer spremeni vrstni red prikaza, toda ne popravi osnovnih podatkov. Rezultati iskanja se vedno prikazujejo napacen datum. Integracija s koledarjem, orodja za skladnost in avtomatizirani delovni toki, ki so odvisni od datuma prejema, se naprej ne delujejo pravilno. In uporabniki morajo pomisliti na spremembo te nastavitve na vsaki napravi in v vsaki mapi.
Ponovna selitev - draga in tvegana
Nekateri skrbniki razmisljajo o ponovni selitvi v upanju, da se bodo datumski tezavi drugic izognili. Ta pristop je drag (500 do 5 000 EUR glede na stevilo predalov), cavsovno zahteven in tvegan. Druga selitev prinese isto tezavo z glavo "Received", podvoji tveganje izgube podatkov in zahteva znaten izpad. Ponovna selitev datumske tezave ne resi, razen ce je selitveno orodje bistveno spremenjeno.
Rocno urejanje glav - zahteva dostop do streznika
Tehnicno popravek vkljucuje odstranitev selitvene glave "Received" iz vsakega e-postnega sporocila. Toda to poceti rocno zahteva neposreden dostop do streznika, poznavanje strukture e-postnih glav in pisanje skript po meri. Za postni predal z 10 000 e-postnimi sporocili je rocno urejanje neprakticno in nevarno nagnjeno k napakam. E-posta s podpisi S/MIME, sifrirana sporocila PGP, vecdelne strukture z ugnedenimi MIME mejami, tezave z Content-Transfer-Encoding, glave z ne-ASCII znaki (RFC 2047), prevelike priloge: vsak od teh primerov lahko povzroci, da osnovna skripta nepovratno poskoduje podatke. Kako potrdite, da je vseh 10 000 popravljenih e-postnih sporocil nedotaknjenih? Ne morete, razen s sistemom preverjanja, zasnovanim posebej za to.
Dejanska resitev - obnovitev izvirnih datumov
Pravilen pristop je identificirati selitvene artefakte v verigi glav vsakega e-postnega sporocila in uporabiti ciljne popravke, ki obnovijo izvirni kronoloski red v vseh e-postnih odjemalcih. To ni preprosto urejanje glav. Proces vkljucuje preverjanje skladnosti z RFC, ohranitev strukture sporocila in ujemanje podpisov selitve iz baze znanih profilov orodij.
Kako Redate.io odpravi to tezavo
Redate.io se poveze s postnim predalom (Google Workspace, Microsoft 365 ali kateri koli IMAP streznik) in analizira vsako e-postno sporocilo za identifikacijo sporocil, prizadetih s selitvenimi glavami. Analiza je brezplacna in prikazuje natancno, koliko e-postnih sporocil je prizadetih, se pred kakrsnimkoli placilom.
Za vsako prizadeto e-postno sporocilo lastniski popravljalni motor Redate.io obdela sporocilo skozi vecstopenjski analiticni cevovod. Motor uporabi ujemanje podpisov na stotinah znanih profilov selitvenih orodij, zgrajenih iz obdelave velikih kolicin dejanskih e-postnih podatkov. Obravnava tezave s kodiranjem, vecdelne strukture, vstavljene priloge in desetine robnih primerov, ki bi povzrocili, da bi skripta DIY poskodovala podatke (ne ta vrsta odkritja, ki jo zelite v ponedeljek zjutraj). Vsako popravljeno e-postno sporocilo gre skozi preverjanje celovitosti pred zakljuckom. Izvorno sporocilo se premakne v vidno mapo "Redate.io - Originals" (ni izbrisano) in se hrani 30 dni.
Rezultat? E-posta prikazuje pravilne izvorne datume v vseh odjemalcih. Razvrscanje spet deluje. Kronoloski zapis postnega predala je obnovljen.
Pogosto zastavljena vprasanja
Ali se datumi lahko popravijo mesece po selitvi?
Da. Izvorna glava "Date" se ohranja znotraj e-postnega sporocila neodvisno od tega, kdaj je selitev potekala. Redate.io lahko popravi datume e-postnih sporocil tedne, mesece ali celo leta po selitvi. Popravek deluje, dokler so izvorne glave e-postnega sporocila nedotaknjene.
Ali bo popravljanje datumov izbrisalo mojo e-posto?
Ne. Redate.io nikoli ne izbrise e-postnih sporocil. Izvorna sporocila se premaknejo v vidno mapo z imenom "Redate.io - Originals" v postnem predalu, kjer ostanejo dostopna 30 dni. Vsako popravljeno e-postno sporocilo se preveri v primerjavi z izvirnikom pred zakljuckom procesa. Ce preverjanje za katero sporocilo ne uspe, izvirnik ostane nedotaknjen.
Ali to deluje s skupnimi postnimi predali?
Da. Redate.io deluje s skupnimi postnimi predali v Google Workspace in Microsoft 365. Za skupne predale je potreben skrbniski dostop za odobritev povezave. Postopek je enak kot pri posameznih predalih: analiza, popravek, preverjanje.
Ste pripravljeni obnoviti pravilne datume? Zazenite brezplacno analizo in odkrijte, koliko e-postnih sporocil je prizadetih v vsakem postnem predalu.