E-kirja kuupäeva muutmine: võimalik ja tuvastatav

E-kirja kuupäeva tagantjärele muutmine: millest täpselt räägime?

See küsimus kerkib regulaarselt süsteemiadministraatorite foorumites ja MSPde Slack-gruppides: kas e-kirja kuupäeva on võimalik pärast saatmist muuta? Lühike vastus on jah, tehniliselt. Kuid täielik vastus on palju vähem julgustav neile, kes seda kahtlastel eesmärkidel teha tahaksid.

E-kiri ei ole ühtne fail. See on tekstipäiste kogum, millele järgneb sõnumi keha. Nende päiste hulgas sisaldab mitu kuupäevaandmeid. Ja mõnda neist on lihtsam muuta kui teisi.

Igas e-kirjas on kolm kuupäevakihti:

• Päis Date: (RFC 2822), mille kirjutab meilirakendus saatmise hetkel
• Päised Received:, mille lisab iga sõnumit edastav server
• IMAP INTERNALDATE, serveripoolne metaandmed, mis on sõnumi sisust sõltumatu

Kõiki neid kihte on võimalik muuta. Ühtegi neist ei saa muuta jälgi jätmata.

Päise Date: muutmine: kõige ilmsem manipulatsioon

Päis Date: on lihttekst .eml-failis. Tehniliselt suudab iga hex-editor või Pythoni skript selle mõne sekundiga ümber kirjutada. Kui olete kunagi Gmailis e-kirja töötlemata päiseid avanud (väike menüü "Kuva originaal"), teate, et see on kõigile loetav.

Probleem? Alates 2004. aastast allkirjastavad valdav enamus meiliservereid väljaminevaid e-kirju DKIMiga (DomainKeys Identified Mail). See krüptograafiline allkiri katab konkreetselt mitut päist, sealhulgas Date:, From:, Subject: ja sõnumi keha. Allkiri talletatakse päises DKIM-Signature:.

Päise Date: muutmine pärast allkirjastamist tühistab DKIMi kontrolli mehhaaniliselt. Iga vastuvõttev server saab allkirja kontrollida, laadides saatja domeeni DNS-ist avaliku võtme. Kui allkiri enam ei klapi, märgitakse sõnum muudetuna. Gmail, Outlook.com ja kõik suuremad teenusepakkujad teevad selle kontrolli automaatselt.

(Muide, kui soovite DKIMi allkirja konkreetselt näha, avage Gmailist või Office 365-st saadud e-kirja töötlemata päised: leiate sealt rea DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., mis näeb välja nagu müra, kuid on tegelikult kogu sõnumi krüptograafiline räsi.)

Tulemus: DKIMiga allkirjastatud e-kirjas päise Date: muutmine purustab pitser. Muudatust näeb iga administraator, kes teab, kust otsida.

Päiste Received: ümbertöötamine: raske võltsida ahel

Päised Received: jälgivad e-kirja läbitud teed saatjalt saajale. Iga SMTP-server, mis sõnumit puudutab, lisab ühe oma nime, IP-aadressi ja ajatempliga. E-kiri, mis läbib kaks või kolm vaheserverit, sisaldab kahte või kolme virnastatud Received: päist.

Kas neid saab muuta? Tehniliselt jah, oma sõnumi koopia puhul. Kuid siin on lõks: saajal on samuti koopia. Ja tema server lisas oma Received: päise viimasena. See päis on saaja kontrolli all, mitte saatja oma. Väljastpoolt on seda võimatu võltsida.

Ahela järjepidevus on kontrollitav. Kui järjestikuste Received: ajatemplid on vastuolulised (näiteks vaheserver oleks sõnumi kätte saanud enne saatja seda saatis), on see kohe kahtlane. Meilide kohtuekspertiisi tööriistad nagu MXToolbox või turvatiimidevahendid kontrollivad täpselt seda.

Tegelikult pole täiesti täpne öelda, et Received: päiseid on täielikult võimatu võltsida: ründaja, kes kontrollib oma meilisõlmi, saab oma hallatavatele vaheserveritele usaldusväärseid päiseid fabrikeerida. Kuid viimast lüli ta ei kontrolli kunagi: saaja serveri.

IMAP INTERNALDATE: kõige tehnilisem juhtum

INTERNALDATE on serveripoolsed IMAP-metaandmed. See pole sõnumis sisalduv päis: see on väärtus, mille server seostab sõnumiga oma sisemises andmebaasis. Seda väärtust kasutab enamik meilirakendusi postkastis sõnumite sortimiseks.

IMAP-käsk APPEND võimaldab sõnumit serverisse üles laadida, määrates konkreetselt INTERNALDATE. See on protokolli seaduslik funktsioon, mis on dokumenteeritud RFC 3501-s. Migratsioonitööriistad kasutavad seda pidevalt: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... kõik laevad e-kirjad sihtserverisse koos määratud INTERNALDATE'iga.

Teoreetiliselt võiks keegi, kellel on IMAP-juurdepääs oma postkastile, laadida sõnumi üles mis tahes INTERNALDATE'iga. Kuid see manipulatsioon ei muuda sõnumi päiseid. Algne Date: jääb puutumata, Received: päised jäävad puutumata, DKIMi allkiri jääb puutumata. Muutub ainult serveripoolne sortimise metaandmed.

Eksperdile, kes uurib töötlemata sõnumit, on INTERNALDATE'i ja Date: vaheline lahknevus kohe näha. Ja kui sõnum on DKIMiga allkirjastatud, on algne kuupäev krüptograafiliselt tõendatud.

Message-ID: raskesti võltsitav sõrmejälg

Iga e-kiri genereerib kordumatu identifikaatori, päise Message-ID:. Selle identifikaatori loob saatva SMTP-serveri saatmise hetkel, kombineerides tavaliselt ajatempli, juhusliku identifikaatori ja serveri domeeninime.

Tüüpiline Message-ID näeb välja nii: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Ajatempel on sageli otse identifikaatorisse kodeeritud. Sõnumi kuupäeva muutmine, jättes Message-ID koos sobimatu ajatempliga, loob kohe märgatava vastuolu.

Lisaks indekseerivad suuremad meilisüsteemid Message-ID-sid. Google, Microsoft ja teised osapooled säilitavad logisid, mis võimaldavad jälgida, millal sõnum nende infrastruktuuris tegelikult liikus. Õiguslikus või kohtuekspertiisi kontekstis on need logid kohtumenetluste kaudu kättesaadavad.

Praktikas: kes suudab manipulatsioonikatset tuvastada?

Esitame küsimuse konkreetselt. Saate e-kirja, mille kuupäeva kahtlustate muudetud olevat. Mida saab IT-administraator või minimaalsete tehniliste teadmistega advokaat teha?

• DKIMi kontroll: Gmailis kuvab menüü "Kuva originaal" DKIMi kontrolli tulemuse lehe ülaosas. "PASS" kinnitab sõnumi terviklust saatmisest saadik. "FAIL" või "SOFTFAIL" annab märku muutmisest.
• Päiste analüüs: tööriistad nagu MXToolbox Header Analyzer või Google Admin Toolbox töötlevad automaatselt Received: ahelat ja tõstavad esile ajalised vastuolud.
• Message-ID ja Date: järjepidevus: analüütik saab võrrelda Message-ID-sse kodeeritud ajatemplit deklareeritud Date: väärtusega.
• Serverilogi: kui e-kiri transiidis läbi serveri, mida te haldate, sisaldavad SMTP-logid sõnumi tegeliku vastuvõtmise kuupäeva ja kellaaega, sõltumata kõigist päistest.

Lühidalt: tuvastustööriistad on kättesaadavad, tasuta ja ei nõua täiustatud kohtuekspertiisi oskusi. Natuke uudishimulik IT-administraator saab e-kirja terviklust kontrollida alla kahe minutiga.

Ainus seaduslik massilise kuupäevamuutmise juhtum: IMAP-migratsioon

On üks stsenaarium, kus sadade tuhandete e-kirjadega juhtub ilma igasuguse pahatahtliku kavatsuseta vale kuupäev: IMAP-migratsioon.

Olete just lõpetanud 150 Exchange'i postkasti migratsiooni Google Workspace'i. Esmaspäeva hommikul hakkavad piletid saabuma. Kasutajad teatavad, et kõik nende vanad e-kirjad kuvatakse sama kuupäevaga, migratsiooninädalavahetusega. Nende postkastid on loetamatud.

Juhtu on dokumenteeritud ja etteaimatav: migratsioonitööriist (BitTitan, CloudM, imapsync, pole vahet) laadis e-kirjad Google Workspace'i IMAP APPENDi kaudu. See määras INTERNALDATE'iks migratsiooni kuupäeva, mitte e-kirja algse kuupäeva. Tulemus: Outlook, mis vaikimisi sortib INTERNALDATE järgi, kuvab kõikide sõnumite puhul migratsioonikuupäeva. Miks e-kirjad näitavad pärast migreerimist valet kuupäeva selgitab seda mehhanismi üksikasjalikult.

Algne päis Date: on igas sõnumis puutumata. DKIMi allkirjad on puutumata. Sisu pole muutunud. Ainult serveripoolne INTERNALDATE on vale.

See probleem puudutab BitTitan MigrationWizi, CloudM Migrate'i, imapsynci, GSMMOd ja kõiki tööriistu, mis kasutavad IMAP APPENDi ilma INTERNALDATE'i korrektselt säilitamata. BitTitan MigrationWizile pühendatud artikkel katab selle tööriista eripärasid. E-posti migratsiooni kuupäevaprobleemide ennetamise kontrollnimekiri loetleb punktid, mida enne ja pärast migratsiooni kontrollida, et sellist probleemi vältida.

Erinevus parandamise ja võltsimise vahel

Redate.io tehtav parandus on võltsimiskatsega diametraalselt vastupidine. Patenteeritud parandusmootor analüüsib iga sõnumi päiste ahelat, tuvastab algse kuupäeva, mis on kodeeritud päisesse Date: (RFC 2822) ja pole kunagi muutunud, ning parandab kuupäeva metaandmed, et need vastaksid sõnumis juba olemasolevale autentsele teabele.

Päis Date: on tõe allikas. Saatja meilirakendus kirjutas selle saatmise hetkel. DKIMi allkiri katab seda. Redate.io ei muuda seda. Parandatakse migratsioonitööriista tekitatud lahknevus, mitte algne kuupäev.

47 000 e-kirja parandamine pärast ebaõnnestunud migratsiooni ühtegi kaotamata, aruteluniite purustamata, manuseid riknemata, Google'i API-l kell 3 öösel 429-viga vallandamata: see on mitmeastmeline analüüsipipeline piirjuhtumite käsitlemisega (S/MIME, PGP, mitte-ASCII kodeeringud RFC 2047 järgi, keerukad multipart-struktuurid). Viierealine Pythoni skript ei elaks esimest tootmispostkasti üle. Kas e-kirjade kuupäevi saab pärast migratsiooni parandada selgitab üksikasjalikult, miks isetegemine on reaalsetel mahtudel riskantne.

Redate.io skannib postkaste tasuta, tuvastab vale kuupäevaga e-kirjad ning parandab need valideerimispipeline kaudu, mis kontrollib iga sõnumit eraldi. Originaalid säilitatakse nähtavas varukaustas 30 päeva jooksul. Kui midagi läheb valesti, on tagasipöördumine võimalik.

Teie migratsioon nihkutas e-kirjade kuupäevi? Käivitage tasuta skannimine Redate.io-s, et mõõta probleemi ulatust enne, kui otsustate, mida teha.