Zakaj e-pošta prikazuje napačen datum po selitvi

Težava - vsa e-pošta prikazuje isti datum

Po IMAP selitvi uporabniki odprejo svoj poštni predal in odkrijejo zaskrbljujoč prizor: vsako e-poštno sporočilo prikazuje točno isti datum. Namesto izvornega datuma pošiljanja ali prejema vsa sporočila nosijo datum, ko je bila selitev izvedena. Leta dopisovanja, ki izgledajo, kot da so prispela na isti dan.

Za IT skrbnike je to nočna mora. Zahtevki se kopicijo, uporabniki ne najdejo ničesar po datumu in kronološki zapis poštnega predala je v praksi uničen.

Kako izgleda v Outlooku

V Microsoft Outlooku stolpec "Prejeto" prikazuje datum selitve za vsako e-poštno sporočilo. Ne glede na to, ali je bilo sporočilo poslano leta 2018 ali 2023, Outlook prikazuje isti datum, dan ko je selitveno orodje obdelalo poštni predal. Prejeta pošta, poslani predmeti, vsaka mapa je prizadeta. Uporabniki, ki se zanašajo na razvrščanje po datumu, imajo delovni tok popolnoma prekinjen.

Kako izgleda v Apple Mail

Apple Mail na macOS in iOS se obnaša podobno. Prikazani datum ob vsakem sporočilu odraža časovni žig selitve namesto izvornega datuma. Ker Apple Mail uporablja metapodatke IMAP strežnika za določanje prikazanih datumov, ista osnovna težava povzroči isti vidni rezultat. Pri pregledovanju prejete pošte vidite samo steno enakih datumov.

Kako izgleda v Gmail (spletni vmesnik)

Spletni vmesnik Gmail predstavlja rahlo drugačno situacijo. Gmailov spletni odjemalec običajno uporabi glavo "Date" iz samega e-poštnega sporočila, zato se sporočila lahko prikazejo s pravilnim datumom v Gmailu. Toda IMAP INTERNALDATE ostane napačen, kar pomeni, da bo vsak IMAP odjemalec, povezan s tem Gmail računom (Outlook, Thunderbird, Apple Mail), prikazal datum selitve. Pravzaprav precej zmedeno, ko isti poštni predal izgleda pravilno v enem odjemalcu, a napačno v drugem.

Zakaj se to dogaja - tehnicni vzrok

Temeljni vzrok je v tem, kako IMAP selitvena orodja obravnavajo glave e-poštnih sporočil in kako e-poštni odjemalci določajo, kateri datum prikazati. Razumevanje tega zahteva kratek vpogled v protokol IMAP in strukturo glav.

Kako IMAP selitvena orodja obravnavajo glave

Ko se e-poštno sporočilo seli z enega strežnika na drugega, selitveno orodje prenese surovo sporočilo z izvornega strežnika in ga naloži na ciljni strežnik s pomočjo ukaza IMAP APPEND. Med tem procesom protokol IMAP zahteva, da ciljni strežnik doda glavo "Received" sporočilu. Ta glava vsebuje časovni žig trenutka, ko je bilo sporočilo vstavljeno v novi strežnik, torej datum selitve.

Glava "Received", ki pokvari vse

E-poštna sporočila običajno vsebujejo več glav "Received", vsako doda poštni strežnik, ki je sporočilo obdelal med izvorno dostavo. Odjemalci kot Outlook določajo "datum prejema" z branjem najnovejše glave "Received", tiste na vrhu verige. Ko selitveno orodje doda novo glavo "Received" s časovnim žigom selitve, ta postane najnovejsa in e-poštni odjemalci prikazejo ta datum namesto izvornega.

To ni napaka selitvenega orodja ali e-poštnega odjemalca. Oba pravilno upostevata standarde IMAP in e-pošte. Težava je v tem, da ti standardi nikoli niso bili zasnovani za mnozicno selitev in interakcija med IMAP APPEND in logiko prikazovanja datumov povzroči ta nezelen rezultat.

INTERNALDATE proti glavi Date

IMAP strežniki hranijo dve razlicni datumski vrednosti za vsako sporočilo. Glava "Date" je del samega e-poštnega sporočila, zapisuje, kdaj je bilo sporočilo prvotno sestavljeno in poslano. INTERNALDATE so metapodatki, ki jih hrani IMAP strežnik, predstavljajo, kdaj je bilo sporočilo dostavljeno ali vstavljeno na ta določen strežnik.

Nekatera selitvena orodja poizkusajo ohraniti izvorni INTERNALDATE z nastavitvijo med ukazom APPEND. Toda tudi ko je INTERNALDATE pravilno nastavljen, dodana glava "Received" se vedno povzroča težave v odjemalcih, ki dajejo prednost datumu "Received" pred INTERNALDATE.

Katera selitvena orodja povzročajo to težavo?

Skoraj vsako IMAP selitveno orodje lahko povzroči to težavo. Težava je lastna protokolu IMAP, ne specifična za določeno orodje. Nekatera so pa pogosteje povezana s težavo zaradi široke 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 povzroči 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 široko uporabljan za selitve Google Workspace. Kot druga orodja tudi CloudM doda svojo glavo "Received" med IMAP vstavljanjem. E-pošta, seljena s CloudM, prikazuje datum selitve v odjemalcih, ki se zanašajo 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. Čeprav imapsync poizkusa ohraniti INTERNALDATE, ciljni strežnik se vedno doda glavo "Received" med operacijo APPEND. FAQ imapsync prizna to omejitev, toda ne ponuja vgrajene rešitve 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 povzroči isto datumsko težavo, zlasti ko selitev vključuje 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 vključuje izvorno funkcijo IMAP uvoza za selitev v Exchange Online (Microsoft 365). To vgrajeno selitveno orodje doda glave "Received" med uvozom, kar povzroči isto težavo s prikazom datumov. Oglejte si vodnike za popravek datumov IMAP selitve Exchange v Outlooku in OWA.

Rocno IMAP kopiranje

Tudi rocno kopiranje e-pošte med IMAP strežniki prek odjemalca kot Thunderbird lahko povzroči to datumsko težavo. Ko e-poštni odjemalec kopira sporočilo prek IMAP, ga ciljni strežnik obravnava kot novo vstavljanje in doda svojo glavo "Received" s trenutnim časovnim žigom. Oglejte si vodnike za popravek datumov rocnega IMAP kopiranja v Outlooku, Gmailu, Thunderbirdu in Apple Mail.

Zakaj običajne zasilne rešitve ne delujejo

Ob soocenju s to težavo uporabniki in skrbniki običajno preizkusijo več pristopov, preden spoznajo, da noben dejansko ne reši težave.

"Razvrstite po datumu pošiljanja" - zakaj to ni dovolj

Najpogostejsi predlog je preklopiti razvrščanje z datuma "prejema" na datum "pošiljanja" v e-poštnem odjemalcu. To sicer spremeni vrstni red prikaza, toda ne popravi osnovnih podatkov. Rezultati iskanja se vedno prikazujejo napačen 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 težavi drugic izognili. Ta pristop je drag (500 do 5 000 EUR glede na število predalov), cavsovno zahteven in tvegan. Druga selitev prinese isto težavo z glavo "Received", podvoji tveganje izgube podatkov in zahteva znaten izpad. Ponovna selitev datumske težave ne reši, razen če je selitveno orodje bistveno spremenjeno.

Rocno urejanje glav - zahteva dostop do strežnika

Tehnično popravek vključuje odstranitev selitvene glave "Received" iz vsakega e-poštnega sporočila. Toda to poceti rocno zahteva neposreden dostop do strežnika, poznavanje strukture e-poštnih glav in pisanje skript po meri. Za poštni predal z 10 000 e-poštnimi sporočili je rocno urejanje nepraktično in nevarno nagnjeno k napakam. E-pošta s podpisi S/MIME, sifrirana sporočila PGP, vecdelne strukture z ugnedenimi MIME mejami, težave z Content-Transfer-Encoding, glave z ne-ASCII znaki (RFC 2047), prevelike priloge: vsak od teh primerov lahko povzroči, da osnovna skripta nepovratno poškoduje podatke. Kako potrdite, da je vseh 10 000 popravljenih e-poštnih sporočil nedotaknjenih? Ne morete, razen s sistemom preverjanja, zasnovanim posebej za to.

Dejanska rešitev - obnovitev izvornih datumov

Pravilen pristop je identificirati selitvene artefakte v verigi glav vsakega e-poštnega sporočila in uporabiti ciljne popravke, ki obnovijo izvorni kronološki red v vseh e-poštnih odjemalcih. To ni preprosto urejanje glav. Proces vključuje preverjanje skladnosti z RFC, ohranitev strukture sporočila in ujemanje podpisov selitve iz baze znanih profilov orodij.

Kako Redate.io odpravi to težavo

Redate.io se poveze s poštnim predalom (Google Workspace, Microsoft 365 ali kateri koli IMAP strežnik) in analizira vsako e-poštno sporočilo za identifikacijo sporočil, prizadetih s selitvenimi glavami. Analiza je brezplačna in prikazuje natančno, koliko e-poštnih sporočil je prizadetih, se pred kakrsnimkoli placilom.

Za vsako prizadeto e-poštno sporočilo lastniski popravljalni motor Redate.io obdela sporočilo skozi večstopenjski analiticni cevovod. Motor uporabi ujemanje podpisov na stotinah znanih profilov selitvenih orodij, zgrajenih iz obdelave velikih kolicin dejanskih e-poštnih podatkov. Obravnava težave s kodiranjem, vecdelne strukture, vstavljene priloge in desetine robnih primerov, ki bi povzročili, da bi skripta DIY poskodovala podatke (ne ta vrsta odkritja, ki jo želite v ponedeljek zjutraj). Vsako popravljeno e-poštno sporočilo gre skozi preverjanje celovitosti pred zakljuckom. Izvorno sporočilo se premakne v vidno mapo "Redate.io - Originals" (ni izbrisano) in se hrani 30 dni.

Rezultat? E-pošta prikazuje pravilne izvorne datume v vseh odjemalcih. Razvrščanje spet deluje. kronološki zapis poštnega predala je obnovljen.

Pogosto zastavljena vprasanja

Ali se datumi lahko popravijo mesece po selitvi?

Da. Izvorna glava "Date" se ohranja znotraj e-poštnega sporočila neodvisno od tega, kdaj je selitev potekala. Redate.io lahko popravi datume e-poštnih sporočil tedne, mesece ali celo leta po selitvi. Popravek deluje, dokler so izvorne glave e-poštnega sporočila nedotaknjene.

Ali bo popravljanje datumov izbrisalo mojo e-pošto?

Ne. Redate.io nikoli ne izbrise e-poštnih sporočil. Izvorna sporočila se premaknejo v vidno mapo z imenom "Redate.io - Originals" v poštnem predalu, kjer ostanejo dostopna 30 dni. Vsako popravljeno e-poštno sporočilo se preveri v primerjavi z izvornikom pred zakljuckom procesa. Če preverjanje za katero sporočilo ne uspe, izvornik ostane nedotaknjen.

Ali to deluje s skupnimi poštnimi predali?

Da. Redate.io deluje s skupnimi poštnimi 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 brezplačno analizo in odkrijte, koliko e-poštnih sporočil je prizadetih v vsakem poštnem predalu.