El. laiško datos keitimas: techninės ribos

El. laiške yra trys „datos". Ne viena.

Kai kalbama apie „gauto el. laiško datos keitimą", dauguma žmonių įsivaizduoja paprastą lauko pakeitimą, panašiai kaip keičiama failo sukūrimo data sistemoje Windows. Tikrovė kiek sudėtingesnė. El. laiškas iš tikrųjų neša tris atskirus datavimo sluoksnius, kurių kiekvienas turi savus taisykles, savus sargus ir savas pasekmes, jei prie jų prisiliečiama.

Suprasti šiuos tris sluoksnius reiškia suprasti, kodėl vieni pataisymai yra techniškai pagrįsti, o kiti arba neįmanomi, arba iš karto atpažįstami kaip klastojimas.

1 sluoksnis: IMAP INTERNALDATE

INTERNALDATE yra serverio pusėje saugoma metaduomenų reikšmė, esanti už paties pranešimo ribų. Ji nėra el. laiško turinio dalis. Ją nustato IMAP serveris, ir būtent ją dauguma el. pašto klientų naudoja laiškams rūšiuoti sąraše.

Outlook, pavyzdžiui, pagal numatytuosius nustatymus rodo pranešimus surūšiuotus pagal INTERNALDATE. Gmail taip pat, tam tikruose kontekstuose. Taigi, jei jūsų INTERNALDATE yra klaidinga, visi el. laiškai sąsajoje atrodo turintys tą pačią datą, nesvarbu, ką byloja vidiniai pranešimo antraštiniai laukai.

INTERNALDATE nustatoma tuo momentu, kai pranešimas patalpinamas į serverį. Naudojant IMAP protokolą, vienintelis būdas ją „pakeisti" yra netiesioginis: reikia naudoti komandą APPEND, kad pranešimo kopija būtų patalpinta su norima data. Komandos SETINTERNALDATE IMAP protokole tiesiog nėra. Šis niuansas bus svarbus vėliau.

2 sluoksnis: antraštinis laukas Date: (RFC 2822)

Tai laukas Date: žaliuosiuose el. laiško antraštiniuose laukuose. Jį nustato el. pašto klientas siuntimo momentu, ir jis keliauja kartu su pranešimu iš serverio į serverį. Tai siuntėjo deklaruota siuntimo data.

(Beje, jei niekada nesate žiūrėję į žalius el. laiško antraštės laukus, tai gana savotiška patirtis. Kiekvienas pranešimas vilkisi apie dvidešimt techninių eilučių, kurių 99 % žmonių niekada nematė.)

Techniškai niekas netrukdo išsiųsti el. laiško su atgaline ar ateitine data lauke Date:. SMTP serveriai šio lauko nepatikrina. Tačiau gavėjų serveriai užfiksuoja faktinį atvykimo laiką antraštiniuose laukuose Received:, o tai iš karto sukuria neatitikimą, matomą bet kuriam el. pašto klientui ar analizės įrankiui.

3 sluoksnis: sukaupti antraštiniai laukai Received:

Kaskart, kai SMTP serveris perduoda pranešimą, jis į steko viršų prideda antraštinį lauką Received: su laiko žyme. El. laiškas, praėjęs per tris serverius, turės tris laukus Received:. Jie skaitomi iš apačios į viršų: seniausias apačioje, naujausias viršuje.

Būtent čia migracijos įrankiai ir sukelia problemą. Kai BitTitan MigrationWiz, CloudM, imapsync ar GSMMO migruoja el. laišką, jie jį pakartotinai įterpia į naują serverį per IMAP. Šis patalpinimas sugeneruoja naują Received: įrašą, pažymėtą migracijos momentu. Rezultatas: seniausias jūsų dėžutės laiškas, el. laiškas iš 2019 metų, gauna Received: datą 2024 m. lapkritį. O kadangi kai kurie el. pašto klientai (Outlook pirmaujant) naujausią Received: naudoja kaip rodoma datą...

Štai ir problema. 15 000 el. laiškų rodo tą pačią migracijos datą.

Ar iš tikrųjų galima „pakeisti" šias datas?

Techniškai taip, INTERNALDATE atveju (su tam tikrais apribojimais). Techniškai įmanoma, bet beprasmiška Date: atveju. O dėl Received: laukų verta sustoti ir pagalvoti.

Perrašyti antraštinį lauką Received: lengva. Ir iš karto aptinkama.

Antraštinis laukas Received: yra tik teksto eilutė pranešime. Jį galima redaguoti kaip bet kurį tekstinį failą. Tikrai taip paprasta, kaip atrodo.

Bet štai kas nutinka toliau.

Pirma problema: DKIM. DKIM parašas (DomainKeys Identified Mail) apskaičiuojamas pagal pranešimo antraštinių laukų rinkinį, kartais įskaitant Received:. Pasirašyto antraštinio lauko pakeitimas parašą padaro negaliojantį. Bet koks gavėjo serveris, tikrinantis DKIM, iš karto matys, kad pranešimas buvo pakeistas. Tai ne subtilus klastojimas, tai aliarmas.

Antra problema: vidiniai identifikatoriai. Šiuolaikiniai pašto serveriai (Google Workspace, Microsoft 365) kiekvienam pranešimui priskiria didėjantį ir unikalų vidinį identifikatorių. Šie identifikatoriai yra susiję su INTERNALDATE ir gavimo tvarka. Keičiant Received: be atitikimo su šiais identifikatoriais sukuriamos neatitiktys, kurias audito įrankiai aptinka be jokių sunkumų.

Trečia problema, praktinė: net jei pakeisite Received: pranešimo turinyje, INTERNALDATE lieka ta pati, t. y. IMAP patalpinimo momentas. El. pašto klientas ir toliau rodo klaidingą rūšiavimo datą. Pakeitėte pranešimą be jokios naudos.

Trumpai tariant. Perrašyti Received: laukus siekiant suklastoti el. laiško datą piktavališkais tikslais: techniškai nesudėtinga, ekspertas aptinka per kelias sekundes. Tai ne rimtas kelias.

Antraštinis laukas Date: arba kaip pakeisti praeitį popieriuje

Ta pati logika taikoma ir laukui Date:. Jį galima pakeisti pranešimo turinye. Tačiau tarpinių serverių autentifikuoti antraštiniai laukai Received: lieka nepalytėti ir pasakoja kitą istoriją. Laiko seka yra nenuosekli. Bet kuris analitikas ar teismas, lyginantis šiuos laukus, tai pamatys iš karto.

Tiksliau kalbant, tai netrukdo kai kuriems el. pašto klientams rodyti pakeistą Date:, jei jiems tiesiogiai pateikiamas .eml failas. Bet gyvo pašto serverio kontekste, su autentifikavimu ir žurnalais, pakeitimas yra visiškai skaidrus.

IMAP migracija: vienintelis kontekstas, kur datos taisymas yra pagrįstas

Yra vienas, ir tik vienas, atvejis, kai el. laiško gavimo datos keitimas yra ne tik įmanomas, bet ir techniškai pagrįstas: žalos, padarytos prastai valdytos IMAP migracijos, taisymas.

Štai konkreti situacija. Ką tik perkėlėte 80 Exchange pašto dėžučių į Microsoft 365. Migracija baigėsi penktadienio vakarą. Pirmadienio rytą pirmieji bilietai pradeda plaukti: „Visi mano el. laiškai rodo tą pačią datą", „Negaliu surasti praeitų metų el. laiško", „Mano istorija su šiuo klientu visiškai sugriauta". Turite 80 blokuotų vartotojų ir vadovą, kuris laukia atsakymo.

Šiame kontekste problema yra dokumentuota, identifikuojama, o jos priežastis aiški: migracijos įrankis pridėjo Received: lauką su migracijos dienos data, ir kai kurie el. pašto klientai šį naują antraštinį lauką naudoja kaip rodoma datą. Originalus antraštinis laukas Date:, tuo tarpu, kiekviename pranešime yra nepalietas. Jis niekada nebuvo pakeistas. Jame vis dar yra originali, teisinga siuntimo data.

Todėl taisymas nėra klastojimas: tai atkūrimas. Pradedama nuo tikrų duomenų (originalaus Date:) ir atkuriami nuoseklūs metaduomenys. Tai iš esmės skiriasi nuo bandymo pateikti 2024 m. el. laišką kaip 2019 m. laišką.

Norėdami sužinoti daugiau apie kiekvieno įrankio specifinius mechanizmus, šie vadovai aprašo konkrečius atvejus: BitTitan datų taisymas Microsoft 365, CloudM datų taisymas Outlook, arba imapsync datų taisymas Google Workspace.

Kodėl rašyti scenarijų pačiam per daug rizikinga

Pagrindinė logika yra prieinama. Bet kuris IT administratorius, praleidęs laiko IMAP forumuose, gali atstatyti bendrą požiūrį. Tai ne problema.

Problema yra atotrūkis tarp scenarijaus, kuris veikia su 50 bandomųjų el. laiškų, ir scenarijaus, kuris be klaidų apdoroja 40 000 pranešimų gamybinėje aplinkoje, neprarasdamas nė vieno el. laiško, nepažeisdamas nė vieno priedo ir nepalaužydamas nė vieno pokalbio gijos.

Keli konkretūs atvejai, kurių naminiai scenarijai paprastai nesutvarko:

• S/MIME pasirašyti el. laiškai: parašas apima turinį ir antraštines eilutes. Bet koks pranešimo struktūros pakeitimas parašą padaro negaliojantį. Neatsargiai pataisytas pasirašytas el. laiškas pas gavėjus atsiranda kaip „neteisingas parašas".
• PGP užšifruoti pranešimai: panaši problemų šeima, su potencialiai blogesnėmis pasekmėmis priklausomai nuo implementacijos.
• Ne-ASCII koduotės antraštinėse eilutėse: RFC 2047 aprašo specialiųjų simbolių kodavimą antraštėse. Scenarijus, kuris manipuliuoja antraštiniais laukais netvarkydamas šių atvejų, tyliai sugadins el. laiškų temas su kirčiuotomis raidėmis, japoniškomis ar arabiškomis raidėmis.
• API užklausų apribojimai: Google Workspace ir Microsoft 365 taiko agresyvų ribojimą. Naktį 3 val., 10 000 el. laiškų paketui, kuris atsitrenkia į klaidą 429 Too Many Requests be eksponentinio atidėjimo valdymo, pusė dėžučių lieka pusiau ištaisyta.
• Sugadintos MIME ribos: daugiaformatiai pranešimai su priedais turi tikslias MIME ribas. Neteisingai jas regeneravus priedai tampa neįskaitomi.

Ir klausimas, kurio joks naminis scenarijus neišsprendžia: kaip patikrinti, kad kiekvienas pataisytas el. laiškas yra nepažeistas? Scenarijus, kuris keičia 40 000 pranešimų be individualaus patikrinimo, yra lažybos. Lažybos su duomenimis, kuriuos jūsų vartotojai dažnai laiko nepakeičiamais.

Straipsnis apie galimas datos taisymo po migracijos parinktis nagrinėja įvairius požiūrius, įskaitant jų atitinkamus apribojimus.

Ką Redate.io daro šiame kontekste

Redate.io sukurtas būtent šiam atvejui: IMAP migracijos sugadintų datų taisymui, dideliu mastu, nekeliant grėsmės pranešimų vientisumui.

Paslauga tiesiogiai jungiasi prie atitinkamų dėžučių (Google Workspace per domeno delegavimą, Microsoft 365 per Azure AD arba tiesiogiai per IMAP), nemokamai nuskaito pranešimus su neteisingomis datomis, tada taiko nuosavybinę taisymo konvejų sistemą, kuri tvarko aukščiau aprašytus kraštutininius atvejus. Kiekvienas el. laiškas tikrinamas atskirai po taisymo. Originalai lieka matomame atsarginių kopijų aplanke 30 dienų.

Šablonų atpažinimas apima šimtus žinomų migracijos įrankių parašų: BitTitan MigrationWiz, CloudM, imapsync, GSMMO ir jų variantus. Aptikimas yra tikslus: Redate.io nepaliečia el. laiškų, kurių data yra teisinga.

Kainodaros modelis paprastas: vienkartinis mokėjimas už kiekvieną pašto dėžutę, be prenumeratos. Diagnostinis nuskaitymas yra nemokamas, taigi galima įvertinti žalos mastą prieš bet ką nusprendžiant.

Jei tvarkote dėžutes, kurias paveikė ši problema, šis straipsnis apie klaidingas datas Outlook po migracijos išsamiai aprašo dažniausius simptomus ir kaip juos atskirti nuo kitų priežasčių.

Pasirengę įvertinti problemos mastą savo dėžutėse? Paleiskite nemokamą nuskaitymą Redate.io ir sužinokite tiksliai, kiek el. laiškų paveikta, dar prieš atliekant bet kokius taisymus.