IMAP INTERNALDATE: zakaj se datumi pokvarijo

Trije datumi v vsakem elektronskem sporočilu

Vsako elektronsko sporočilo, shranjeno na strežniku IMAP, vsebuje vsaj tri različne datumske vrednosti. Razumevanje delovanja teh datumov in načina, kako e-poštni odjemalci izberejo, katerega prikazati, je ključ do razumevanja, zakaj migracija pokvari datume. Ta članek je poglobljen tehničen pregled sistema datumov IMAP, namenjen IT skrbnikom in vsem, ki želijo razumeti temeljni vzrok težav z datumi po migraciji.

1. Glava RFC 2822 "Date"

Glava "Date" je opredeljena v RFC 2822 (Internet Message Format). Nastavi jo pošiljateljev e-poštni odjemalec v trenutku, ko je sporočilo sestavljeno in poslano. Ta glava je del samega telesa e-poštnega sporočila - potuje s sporočilom in je poštni strežniki na poti dostave nikoli ne spreminjajo. Tipična glava Date izgleda takole:

Date: Mon, 15 Jan 2024 09:32:17 +0100

Glava Date predstavlja "datum pošiljanja" sporočila. Je najzanesljivejši datum, ker je nastavljen enkrat in se nikoli ne spremeni. Vendar odraža uro pošiljatelja, ki je lahko napačno nastavljena. V redkih primerih lahko glava Date povsem manjka (zlasti pri avtomatiziranih sistemskih obvestilih ali nepravilno oblikovanih sporočilih).

2. IMAP INTERNALDATE

INTERNALDATE je opredeljen v RFC 3501 (protokol IMAP4rev1). Gre za metapodatkovno vrednost na strani strežnika, ki predstavlja datum in čas, ko je bilo sporočilo dostavljeno na strežnik. Za razliko od glave Date, INTERNALDATE ni del samega e-poštnega sporočila. Strežnik IMAP ga shranjuje ločeno kot metapodatek.

Ko je e-pošta dostavljena normalno (brez migracije), strežnik IMAP nastavi INTERNALDATE na trenutni čas v trenutku dostave. To se tesno ujema z glavo Date, običajno v razponu sekund ali minut. E-poštni odjemalci pogosto uporabljajo INTERNALDATE kot "datum prejema", ker odraža, kdaj je strežnik dejansko prejel sporočilo.

Tukaj postane zanimivo. Ko je sporočilo vstavljeno prek ukaza IMAP APPEND (ki ga uporabljajo migracijska orodja), ukaz APPEND odjemalcu omogoča, da izrecno določi INTERNALDATE. Dobro zasnovana migracijska orodja uporabljajo to funkcijo za ohranitev izvirnega INTERNALDATE iz izvornega strežnika. Toda tudi ko je INTERNALDATE pravilno nastavljen, lahko težava z glavo "Received" (opisana spodaj) še vedno preglasi prikazani datum v številnih e-poštnih odjemalcih.

3. Veriga glav "Received"

Vsakič, ko elektronsko sporočilo potuje skozi poštni strežnik, ta strežnik na začetek sporočila doda glavo "Received". S tem nastane veriga glav Received, ki beleži pot, ki jo je e-pošta prepotovala od pošiljatelja do prejemnika. Najnovejša (zgornja) glava Received prikazuje zadnji strežnik, ki je obravnaval sporočilo, najstarejša (spodnja) pa prvega.

Normalna e-pošta ima lahko od 3 do 6 glav Received, ki dokumentirajo pot od pošiljateljevega odhodnega strežnika prek morebitnih posredniških strežnikov do prejemnikovega dohodnega strežnika. Vsaka glava Received vključuje časovni žig. Tukaj je poenostavljen primer:

Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

Kako e-poštni odjemalci izberejo, kateri datum prikazati

Outlook (namizje, splet, mobilno)

Microsoft Outlook uporablja kombinacijo INTERNALDATE in zgornje glave "Received" za določitev "prejetega" datuma, prikazanega v mapi prejete pošte. V praksi Outlook daje prednost časovnemu žigu iz najnovejše glave Received za stolpec "Prejeto". Stolpec "Poslano" uporablja glavo Date. Ker Outlook privzeto razvrščanje izvaja po stolpcu "Prejeto", je časovni žig glave Received tisto, kar uporabniki vidijo najprej.

Apple Mail

Apple Mail na macOS in iOS primarno uporablja IMAP INTERNALDATE za prikaz datuma. Če je bil INTERNALDATE pravilno ohranjen med migracijo, lahko Apple Mail prikaže pravilen datum, vendar le, če je bil INTERNALDATE izrecno nastavljen med operacijo APPEND. Če migracijsko orodje ni nastavilo INTERNALDATE, strežnik privzeto uporabi čas vstavljanja (datum migracije). Za podrobnosti o tem, kako to vpliva na uporabnike Apple Mail, glejte Apple Mail - napačen datum po migraciji.

Thunderbird

Mozilla Thunderbird ponuja največ prilagodljivosti. Lahko prikaže tako "Datum" (iz glave Date) kot "Prejeto" (iz glav Received). Privzeto Thunderbird prikazuje vrednost glave Date, kar pomeni, da se datumi v Thunderbirdu lahko zdijo pravilni, čeprav so v Outlooku napačni. Stolpec "Prejeto" v Thunderbirdu pa pravzaprav še vedno prikazuje datum migracije. Za več podrobnosti glejte Thunderbird - napačen datum po migraciji.

Spletni vmesnik Gmail

Gmailov spletni odjemalec za primarni prikaz datuma uporablja glavo Date. To pomeni, da Gmail na spletu pogosto prikazuje pravilne datume tudi po migraciji. Toda IMAP INTERNALDATE na strežniku Gmail je še vedno napačen, kar vpliva na vsak odjemalec IMAP, ki se poveže s tem računom Gmail. Neskladje med spletnim Gmailom in Outlookom ali Apple Mailom je pogost vir zmede in eden, ki zapravlja veliko časa skrbnikom pri odpravljanju težav.

Zakaj IMAP APPEND pokvari datume

Kaj se zgodi med migracijo

Ko migracijsko orodje premakne elektronsko sporočilo s strežnika A na strežnik B, se orodje poveže na strežnik A prek IMAP in prenese surovo sporočilo, nato se poveže na strežnik B in uporabi ukaz APPEND za vstavljanje. Med tem vstavljanjem strežnik B obdela dohodno sporočilo in doda novo glavo Received s trenutnim časovnim žigom - datumom migracije. To je pogosto vedenje strežnikov IMAP pri operaciji APPEND. Strežnik obravnava vsak APPEND kot novo dostavo sporočila.

Rezultat: kontaminirana veriga glav

Po migraciji glave Received elektronskega sporočila izgledajo takole:

Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

Glava Received migracijskega orodja je zdaj zgornji vnos. Vsak e-poštni odjemalec, ki za določitev prikaznega datuma uporablja zgornjo glavo Received (še posebej Outlook), bo prikazal "11. april 2025" namesto "15. januar 2024." Izvirna glava Date in izvirne glave Received so še vedno nedotaknjene spodaj, vendar niso več na mestu, ki mu e-poštni odjemalci dajejo prednost.

Tudi dobro ravnanje z INTERNALDATE tega ne prepreči

Nekatera migracijska orodja pravilno nastavijo INTERNALDATE med APPEND. Na primer, imapsync izrecno ohranja INTERNALDATE izvornega strežnika. Toda glavo Received doda ciljni strežnik, ne migracijsko orodje. Migracijsko orodje nad tem vedenjem nima nadzora. Tudi ob popolni ohranitvi INTERNALDATE zgornja glava Received še vedno vsebuje datum migracije in odjemalci, kot je Outlook, še vedno prikazujejo napačen datum.

Kaj torej dejansko lahko storite glede tega?

Katera migracijska orodja dodajo glave Received

Vsako migracijsko orodje IMAP povzroča to težavo, ker glavo Received doda ciljni strežnik, ne migracijsko orodje samo. Vsebina dodane glave pa se razlikuje glede na orodje in strežnik.

BitTitan MigrationWiz doda glavo Received, ki vsebuje "mx.migrationwiz.com." CloudM Migrate doda glave, ki se sklicujejo na "cloudm.io." imapsync sproži generično glavo Received s ciljnega strežnika. GSMMO doda glave s sklici na "gmailapi.google.com".

Popravek: obnovitev pravilnih datumov

Dobra novica je, da pravilne datumske informacije še vedno obstajajo v vsakem elektronskem sporočilu. Izvirna glava Date je nedotaknjena. Izvirne glave Received so nedotaknjene. Težava je v tem, da kontaminirajoča glava sedi na vrhu.

Lastniški korekcijski mehanizem Redate.io analizira celotno verigo glav vsakega prizadetega elektronskega sporočila in z zaznavanjem nepravilnosti v datumih natančno identificira, katere glave potrebujejo popravek. Ta pristop deluje ne glede na to, katero migracijsko orodje je bilo uporabljeno. Večstopenjski analizni cevovod obravnava robne primere, ki preprostejše pristope spravijo v težave: sporočila s podpisom S/MIME, vsebino šifrirano s PGP, strukture multipart/alternative, težave s Content-Transfer-Encoding, glave z znaki izven ASCII (RFC 2047), prevelike priloge in poškodovane meje MIME.

Po popravku vsako elektronsko sporočilo prestane postopek preverjanja celovitosti, ki potrdi, da so struktura sporočila, vsebina in priloge ohranjene natančno. Izvirniki se ne izbrišejo samodejno: premaknejo se v vidno varnostno mapo v poštnem predalu, kjer ostanejo, dokler jih stranka ne odstrani.

Ali bi lahko sami napisali skripto za to? Tehnično gledano, da. Toda razlika med "deluje pri 95 % e-pošte" in "deluje pri 100 % e-pošte brez poškodbe enega samega sporočila" je tisto, kamor gredo meseci inženirskega dela. In ko govorimo o celotnem poštnem predalu nekoga, tista 5-odstotna stopnja napak pomeni na stotine tiho poškodovanih sporočil brez možnosti preverjanja, kaj je šlo narobe.

Želite videti, koliko elektronskih sporočil v vašem poštnem predalu ima pokvarjene datume? Zaženite brezplačno skeniranje z Redate.io za takojšnje število prizadetih sporočil, brez potrebe po plačilu.