Trys datos kiekvieno el. laiško viduje
Kiekvienas IMAP serveryje saugomas el. laiškas turi bent tris atskiras datų reikšmes. Supratimas, kaip šios datos veikia ir kaip el. pašto klientai pasirenka, kurią rodyti, yra raktas suprasti, kodėl migracija sugadina datas. Šis straipsnis yra gilus techninis IMAP datų sistemos tyrimas, skirtas IT administratoriams ir visiems, norintiems suprasti datų problemų po migracijos pagrindinę priežastį.
1. RFC 2822 „Date" antraštė
Antraštė „Date" apibrėžta RFC 2822 (interneto pranešimų formatas). Ją nustato siuntėjo el. pašto klientas pranešimo kūrimo ir siuntimo metu. Ši antraštė yra paties pranešimo dalis - ji keliauja kartu su pranešimu ir niekada nėra modifikuojama el. pašto serverių pristatymo kelyje. Tipinė „Date" antraštė atrodo taip:
Date: Mon, 15 Jan 2024 09:32:17 +0100
„Date" antraštė atspindi pranešimo „išsiuntimo datą". Tai patikimiausia data, nes ji nustatoma vieną kartą ir niekada nekeičiama. Tačiau ji atspindi siuntėjo laikrodį, kuris gali būti neteisingai sukonfigūruotas. Retais atvejais „Date" antraštė gali visai nebūti (ypač automatizuotuose sisteminiuose pranešimuose ar netinkamai suformuotuose pranešimuose).
2. IMAP INTERNALDATE
INTERNALDATE apibrėžta RFC 3501 (IMAP4rev1 protokolas). Tai serverio pusės metaduomenų reikšmė, atspindinti datą ir laiką, kada pranešimas buvo pristatytas serveriui. Skirtingai nei „Date" antraštė, INTERNALDATE nėra paties el. laiško dalis. Ji saugoma atskirai IMAP serverio kaip metaduomuo.
Kai el. laiškas pristatomas įprastai (ne migruojamas), IMAP serveris nustato INTERNALDATE į esamą pristatymo laiką. Ši reikšmė artima „Date" antraštei, paprastai skiriasi keliomis sekundėmis ar minutėmis. El. pašto klientai dažnai naudoja INTERNALDATE kaip „gavimo datą", nes ji atspindi momentą, kai serveris iš tiesų gavo pranešimą.
Ir čia tai tampa įdomu. Kai pranešimas įterpiamas per IMAP APPEND komandą (ką naudoja migracijos įrankiai), APPEND komanda leidžia klientui nurodyti INTERNALDATE tiesiogiai. Gerai suprojektuoti migracijos įrankiai naudoja šią savybę, kad išsaugotų originalią šaltinio serverio INTERNALDATE. Tačiau net kai INTERNALDATE teisingai nustatyta, „Received" antraštės problema (aprašyta žemiau) vis tiek gali nustelbti rodomą datą daugelyje klientų.
3. „Received" antraščių grandinė
Kiekvieną kartą, kai el. laiškas praeina per el. pašto serverį, tas serveris prideda „Received" antraštę pranešimo pradžioje. Tai sukuria „Received" antraščių grandinę, fiksuojančią el. laiško kelionę nuo siuntėjo iki gavėjo. Naujausia (viršuje) rodo paskutinį serverį, apdorojusį pranešimą, o seniausia (apačioje) rodo pirmąjį.
Įprastas el. laiškas gali turėti 3-6 „Received" antraštes, dokumentuojančias kelionę nuo siuntėjo išsiunčiamojo serverio per perdavimo taškus iki gavėjo gaunamojo serverio. Kiekviena „Received" antraštė turi laiko žymą. Štai supaprastintas pavyzdys:
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
Kaip el. pašto klientai pasirenka, kurią datą rodyti
„Outlook" (darbalaukio, žiniatinklio, mobilusis)
„Microsoft Outlook" naudoja INTERNALDATE ir naujausios „Received" antraštės kombinaciją „Gavimo" datai, rodomei gautuosiuose, nustatyti. Praktiškai „Outlook" linkęs teikti pirmenybę naujausios „Received" antraštės laiko žymai stulpeliui „Gauta". Stulpelis „Išsiųsta" naudoja „Date" antraštę. Kadangi „Outlook" pagal numatytuosius nustatymus rūšiuoja pagal stulpelį „Gauta", būtent „Received" antraštės laiko žymą naudotojai mato pirmiausia.
„Apple Mail"
„Apple Mail" „macOS" ir „iOS" pirmiausia naudoja IMAP INTERNALDATE datai rodyti. Jei INTERNALDATE buvo teisingai išsaugota migracijos metu, „Apple Mail" gali rodyti teisingą datą, bet tik jei INTERNALDATE buvo tiesiogiai nustatyta per APPEND operaciją. Jei migracijos įrankis nenustatė INTERNALDATE, serveris naudoja numatytąjį įterpimo laiką (migracijos datą). Informacijai apie poveikį „Apple Mail" naudotojams žr. „Apple Mail": klaidinga data po migracijos.
„Thunderbird"
„Mozilla Thunderbird" siūlo daugiausiai lankstumo. Jis gali rodyti tiek „Data" (iš „Date" antraštės), tiek „Gauta" (iš „Received" antraščių). Pagal numatytuosius nustatymus „Thunderbird" rodo „Date" antraštės reikšmę, o tai reiškia, kad datos „Thunderbird" gali atrodyti teisingos net kai jos klaidingos „Outlook". Stulpelis „Gauta" „Thunderbird" visada rodo migracijos datą. Žr. „Thunderbird": klaidinga data po migracijos daugiau informacijos.
„Gmail" žiniatinklio sąsaja
„Gmail" žiniatinklio klientas naudoja „Date" antraštę pagrindiniam datos rodymui. Tai reiškia, kad „Gmail" žiniatinklis dažnai rodo teisingas datas net po migracijos. Tačiau IMAP INTERNALDATE „Gmail" serveryje vis tiek klaidinga, o tai paveikia kiekvieną IMAP klientą, prisijungiantį prie šios „Gmail" paskyros. Skirtumas tarp „Gmail" žiniatinklio ir „Outlook" ar „Apple Mail" yra dažnas painiavos šaltinis ir priežastis, kodėl administratoriai praranda daug derinimo laiko.
Kodėl IMAP APPEND sugadina datas
Kas nutinka migracijos metu
Kai migracijos įrankis perkelia el. laišką iš Serverio A į Serverį B, įrankis prisijungia prie Serverio A per IMAP ir atsisiunčia neapdorotą pranešimą, tada prisijungia prie Serverio B ir naudoja APPEND komandą jam įterpti. Šio įterpimo metu Serveris B apdoroja gaunamą pranešimą ir prideda naują „Received" antraštę su esama laiko žyma - migracijos data. Tai standartinis IMAP elgesys, apibrėžtas protokole. Serveris traktuoja kiekvieną APPEND kaip naują pranešimo pristatymą.
Rezultatas: užteršta antraščių grandinė
Po migracijos el. laiško „Received" antraštės atrodo taip:
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
Migracijos įrankio „Received" antraštė dabar yra aukščiausias įrašas. Bet kuris el. pašto klientas, naudojantis naujausią „Received" antraštę rodomai datai nustatyti (ypač „Outlook"), rodys „2025 m. balandžio 11 d." vietoj „2024 m. sausio 15 d.". Originali „Date" antraštė ir originalios „Received" antraštės vis dar nepažeistos žemiau, bet jos nebe toje pozicijoje, kuriai el. pašto klientai teikia pirmenybę.
Net geras INTERNALDATE tvarkymas to neužkerta
Kai kurie migracijos įrankiai teisingai nustato INTERNALDATE per APPEND. Pavyzdžiui, imapsync tiesiogiai išsaugo šaltinio serverio INTERNALDATE. Tačiau „Received" antraštę prideda paskirties serveris, o ne migracijos įrankis. Migracijos įrankis neturi jokio šio elgesio valdymo. Net su tobulu INTERNALDATE išsaugojimu, aukščiausia „Received" antraštė vis tiek turi migracijos datą, ir tokie klientai kaip „Outlook" vis tiek rodo klaidingą datą.
Taigi, ką konkrečiai galima padaryti?
Kurie migracijos įrankiai prideda „Received" antraštes
Visi IMAP migracijos įrankiai sukelia šią problemą, nes „Received" antraštę prideda paskirties serveris, o ne pats įrankis. Pridėtos antraštės turinys skiriasi priklausomai nuo įrankio ir serverio.
BitTitan MigrationWiz prideda „Received" antraštę su „mx.migrationwiz.com". CloudM Migrate prideda antraštes su nuoroda „cloudm.io". imapsync sukelia bendrą paskirties serverio „Received" antraštę. GSMMO prideda antraštes su nuoroda „gmailapi.google.com".
Taisymas: teisingų datų atkūrimas
Gera žinia ta, kad teisinga datos informacija vis dar egzistuoja kiekviename el. laiške. Originali „Date" antraštė nepažeista. Originalios „Received" antraštės nepažeistos. Problema ta, kad užteršianti antraštė sėdi virš jų.
Redate.io nuosavybinis taisymo variklis analizuoja kiekvieno paveikto el. laiško visą antraščių grandinę, taikydamas parašų atitikimą šimtams žinomų migracijos įrankių parašų, kad tiksliai identifikuotų, kurios antraštės reikalauja korekcijos. Daugiapakopis analizės konvejeris tvarko ribinius atvejus, kurie sugadintų paprastesnius metodus: S/MIME pasirašytus pranešimus, PGP šifruotą turinį, multipart/alternative struktūras, Content-Transfer-Encoding problemas, ne ASCII antraštes (RFC 2047), per didelius priedus ir sugadintas MIME ribas.
Po taisymo kiekvienas el. laiškas praeina vientisumo patikros procesą, patvirtinantį, kad pranešimo struktūra, turinys ir priedai yra identiški originui. Originalai saugomi matomame atsarginės kopijos aplanke 30 dienų.
Ar galima parašyti scenarijų ir bandyti šį taisymą patiems? Techniškai taip. Tačiau skirtumas tarp „tai veikia 95 % el. laiškų" ir „tai veikia 100 % el. laiškų nesugadindamas nė vieno" atspindi mėnesius kūrimo. O kai kalbama apie kieno nors visą pašto dėžutę, 5 % nesėkmės rodmuo reiškia šimtus tyliai sugadintų pranešimų be būdo patikrinti, kas nutiko ne taip.
Norite sužinoti, kiek el. laiškų jūsų pašto dėžutėje turi klaidingas datas? Paleiskite nemokamą analizę su Redate.io ir gaukite momentinį paveiktų el. laiškų skaičių, be jokio mokėjimo.