Gauto el. laiško data: ką iš tikrųjų galima keisti?

Klausimas, kurį visi užduoda (ir kodėl jis slepia dvi labai skirtingas situacijas)

Įveskite „pakeisti gauto el. laiško datą" į „Google". Rasite dešimtis temų „Microsoft Q&A" forumuose, „Reddit" gijų, „Quora" klausimų. Poreikis aiškus, tačiau priežastys, dėl kurių klausiama, radikaliai skiriasi priklausomai nuo to, kas klausia.

Vieni ieško, kaip suklastoti datą retrospektyviai, dėl priežasčių, kurių geriau neįsivaizduoti. Kiti - IT administratoriai, kurie po IMAP migracijos mato, kad visi el. laiškai rodo tą pačią dieną (migracijos dieną), ir tiesiog nori susigrąžinti tikrąsias datas. Šios dvi situacijos neturi nieko bendro, tačiau joms abiem naudojama ta pati paieškos formuluotė.

Šis straipsnis atsako į abu klausimus. Spoileris: pirmuoju atveju modifikacijos neįmanoma atlikti nepastebėtai. Antruoju - ji visiškai teisėta, ir būtent tai daro Redate.io.

Pirma: kas yra el. laiško „data"?

El. laiške yra ne viena data. Jų yra kelios, saugomos skirtingose vietose, kontroliuojamos skirtingų subjektų.

Antraštė Date: (RFC 2822)

Tai data, kurią siuntėjo el. pašto klientas įrašo į pranešimą siuntimo metu. Ji matoma neapdorotose antraštėse tokiu formatu:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Ši antraštė yra pranešimo turinio dalis. Techniškai ją galima modifikuoti, jei turite prieigą prie neapdoroto failo. Tačiau žodis „techniškai" čia yra labai svarbus.

Antraštės Received:

Kiekvienas pašto serveris, per kurį praeina el. laiškas, prideda savo Received: antraštę su laiko žyma. Šios antraštės sudaro chronologinę grandinę - nuo siuntėjo serverio iki jūsų dėžutės. (Beje, jei kada nors bandėte skaityti neapdorotas el. laiško antraštes, žinote, kad tai nėra lengvas skaitymas. Kelios dešimtys eilučių techninių metaduomenų, išdėstytų nuo naujausių iki seniausių.)

IMAP INTERNALDATE

Tai svarbiausi metaduomenys norint suprasti, kodėl kai kurios modifikacijos neturi jokio matomo poveikio. INTERNALDATE yra atributas, saugomas IMAP serverio pusėje, nepriklausomai nuo pranešimo turinio. Būtent jį dauguma el. pašto klientų naudoja el. laiškams rūšiuoti aplankuose. „Outlook" jį naudoja. „Gmail" taip pat. „Apple Mail" daugeliu atvejų irgi.

INTERNALDATE nėra pranešime. Jis yra serverio duomenų bazėje. Jūs negalite jo pakeisti redaguodami .eml failą savo diske.

Kas iš tikrųjų nutinka, kai redaguojate lokaliai

.eml failo redagavimas

Techniškai .eml failas yra tekstinis failas. Galite jį atidaryti redaktoriuje, pakeisti eilutę Date:, išsaugoti. Jei šį failą reimportuosite į lokalų el. pašto klientą, rodoma data gali pasikeisti - priklausomai nuo kliento.

Tačiau štai ko tai nekeičia:

• INTERNALDATE IMAP serveryje (vis tiek nepakeistas)
• Tarpinių serverių pridėtos Received: antraštės
• Pristatymo žurnalai „Google", „Microsoft" ar jūsų tiekėjo serveriuose
• DKIM parašas, jei pranešimas jį turėjo

Rezultatas: jūsų lokaliai galbūt matote kitokią datą. Tačiau „Outlook", prijungtas prie „Exchange Online", ar „Gmail" naršyklėje - niekas nepasikeitė.

Sistemos laikrodžio keitimas

Kai kuriuose forumuose siūloma pakeisti darbo stoties laikrodį, siekiant „apgauti" el. pašto klientą. Tai neveikia. „Outlook" ir „Gmail" nenuskaito sistemos laiko rodyti gautų laiškų datoms. Jie skaito INTERNALDATE iš serverio arba pranešimo antraštes. Lokalus laikrodis šiame procese nedalyvauja.

Manipuliavimas per Thunderbird

„Thunderbird" suteikia daugiau lankstumo nei dauguma klientų. Naudojant plėtinius arba tiesiogiai manipuliuojant profiliu (mbox failai, .msf failai), kai kas bando pakeisti datų rodinį. Tai gali veikti pačiame „Thunderbird", el. laiškams, saugomiems lokaliai POP3 režimu. Tačiau kai tik „Thunderbird" prijungiamas per IMAP, jis iš naujo sinchronizuojasi su serveriu. „Pataisa" dingsta kitą sinchronizacijos kartą.

DKIM: nematomoji barjeras, apie kurią niekas nekalba

Dauguma el. laiškų, siųstų nuo 2018 m., yra pasirašyti DKIM (DomainKeys Identified Mail). DKIM parašas antraštėse atrodo taip:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Laukas h= išvardija parašu apimtas antraštes. Aukščiau pateiktame pavyzdyje Date yra pasirašyta. Jei pakeisite pranešimo antraštę Date:, DKIM tikrinimas nepavyks. Bet kuris pašto serveris, bet kuris kriminalistikos analizės įrankis, gali aptikti modifikaciją perskaičiuodamas parašą.

Tai nėra tobula apsauga (kenkėjiškas siuntėjas valdo savo DKIM raktą ir gali pasirašyti ką nori siuntimo metu). Tačiau el. laiškui, jau gautam ir pasirašytam, Date: antraštės keitimas palieka aptinkamą pėdsaką.

Serverio žurnalai: tikrasis tiesos šaltinis

Net jei pavyktų pakeisti visus matomus el. laiško metaduomenis (antraštes, INTERNALDATE, viską), tiekėjai saugo savus žurnalus.

„Google Workspace" registruoja kiekvieną pranešimą „Admin Console" audito žurnaluose. „Microsoft 365" daro tą patį „Compliance Center" (Purview). Šie žurnalai apima pristatymo laiko žymas, nepriklausomai nuo to, kas rodoma klientuose. Teisininkas, teisinis skyrius ar informacijos saugos komanda gali gauti šiuos duomenis. Data, matoma „Outlook", neturi juridinės galios teisme ar saugos audito metu.

Tiksliau: net administratorius, turintis prieigą prie dėžutės per domeno delegavimą, negali retrospektyviai perrašyti šių žurnalų. Jie nepasiekiami net privilegijuotiems vartotojams.

Teisėtas atvejis: taisymas po migracijos

Ką tik baigėte 150 dėžučių migraciją iš „Exchange" vietinio serverio į „Microsoft 365". Pirmadienio rytą plūsta bilietai: „visi mano seni laiškai datuoti praėjusiu penktadieniu". Migracijos diena.

Tai gerai dokumentuota problema, visiškai skirtinga nuo to, ką ką tik aprašėme. Čia niekas nesiekia nieko suklastoti. Tikrosios originalios datos vis dar egzistuoja, nepažeistos, kiekvieno pranešimo antraštėje Date:. Problema kitur: migracijos įrankis (BitTitan MigrationWiz, CloudM, imapsync ar kitas) grandinės pradžioje įterpė Received: antraštę su migracijos data. „Outlook", tam tikruose kontekstuose besiremiančios naujesnėmis Received: antraštėmis, o ne INTERNALDATE, vietoj tikrosios datos rodo šią datą.

Šiuo atveju „taisymas" reiškia suderinamumo atstatymą tarp to, ką sako pranešimas (originalus Date:, vis dar ten), ir to, ką mano serveris (INTERNALDATE, nustatytas migracijos metu). Tai ne klastojimas. Tai atkūrimas.

Būtent tai aprašoma, kai netinkamai sukonfigūruota migracija primeta šią problemą tūkstančiams dėžučių. Ir būtent tai sprendžia Redate.io.

Kodėl „pasidaryk pats" neveikia dideliu mastu

Suprasti problemą yra viena. Ištaisyti ją 40 000 el. laiškų, paskirstytų per 150 dėžučių, neprarandant nė vieno, yra kitas dalykas.

Skriptai, kuriuos rasite „GitHub" ar „Stack Overflow", veikia su 20 bandomųjų el. laiškų. Gamyboje jie susiduria su problemomis, kurių skriptų autoriai nenumatė:

• S/MIME pasirašyti ar PGP šifruoti el. laiškai turi struktūras, kuriomis negalima manipuliuoti kaip įprastais pranešimais
• Daugiadaliai pranešimai su nestandartinėmis MIME ribomis sukelia analizės klaidas
• RFC 2047 koduotos antraštės (ne ASCII simboliai laukuose From: ar Subject:) sulaužo naivius analizatorius
• „Google" ir „Microsoft" API taiko užklausų ribojimą (rate limiting): 3 valandą ryto, apdorojant 30 000 el. laiškų paketą, 429 Too Many Requests klaida nėra apdorojama, skriptas sustoja, ir niekas nežino, kur jis sustojo
• Nėra grįžimo mechanizmo: jei pranešimas sugadinamas apdorojimo metu, nėra nieko, kuo grįžti atgal

Redate.io saugo kiekvieno originalaus el. laiško kopiją matomame atsarginių kopijų aplanke 30 dienų. Kiekviena pataisa tikrinama atskirai. Analizės konvejeris apdoroja šimtus žinomų migracijos įrankių parašų, taip pat visus kraštutinių atvejų scenarijus, kurių naminis skriptas netvarkytų.

Daugiau informacijos apie specifiką pagal naudojamą įrankį: BitTitan MigrationWiz ir el. laiškų datos, arba CloudM Migrate: kaip pataisyti neteisingus datus.

Kas keičiasi, kas niekada nesikeičia

Skirtumas aiškus. Pirmosios trys lentelės eilutės aprašo paviršutiniškas arba aptinkamas modifikacijas. Paskutinė aprašo teisėtą metaduomenų taisymą, suderintą su originaliu pranešimo turiniu, po migracijos, kuri įvedė neatitikimą.

Jei esate situacijoje, aprašytoje lentelės apačioje, po migracijos su imapsync, BitTitan, CloudM ar kitu įrankiu, Redate.io skirtas būtent tam.

Jūsų el. laiškai rodo migracijos datą vietoj tikrųjų datų? Nuskenuokite savo dėžutes nemokamai su Redate.io ir sužinokite tiksliai, kiek el. laiškų yra paveikti, prieš priimdami sprendimą.