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

Küsimus, mida kõik esitavad (ja miks see peidab kahte täiesti erinevat olukorda)

Sisestage Google'i otsingusse "saadud e-kirja kuupäeva muutmine". Leiate kümneid Microsoft Q&A foorumite teemasid, Reddit'i lõime, Quora küsimusi. Soov on selge, kuid selle taga olevad põhjused on küsijast sõltuvalt täiesti erinevad.

On neid, kes tahavad kuupäeva tagasiulatuvalt võltsida põhjustel, mille üle on parem mitte pikalt arutleda. Ja on IT-administraatoreid, kes näevad pärast IMAP-migratsiooni, et kõik meilid kuvavad sama kuupäeva (migratsioonipäeva), ja tahavad lihtsalt algupärased kuupäevad taastada. Neil kahel olukorral pole omavahel midagi pistmist, kuid mõlemad kasutavad sama otsingusõnastust.

See artikkel vastab mõlemale. Lühidalt: esimesel juhul pole muutmine tegelikult märkamatult teostatav. Teisel juhul on see täiesti seaduslik ja just seda Redate.io teeb.

Kõigepealt: mis on e-kirja "kuupäev"?

E-kirjas pole ainult üks kuupäev. Neid on mitu, salvestatud erinevatesse kohtadesse, mida kontrollivad erinevad osapooled.

Päis Date: (RFC 2822)

See on kuupäev, mille saatja meiliklient kirjutab sõnumisse saatmise hetkel. See on töötlemata päistes nähtav järgmisel kujul:

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

See päis on sõnumi sisu osa. Seda on tehniliselt võimalik muuta, kui pääsete ligi töötlemata failile. Kuid "tehniliselt" on siin võtmesõna.

Päised Received:

Iga meiliserverit, mille kaudu sõnum läbib, lisab oma Received: päise koos ajatempliga. Need päised moodustavad kronoloogilise ahela saatja serverist teie postkastini. (Muide, kui olete kunagi proovinud lugeda e-kirja töötlemata päiseid, teate, et see pole just lõpuniloetava raamatu moodi. Kümned read tehnilisi metaandmeid järjekorras, mis läheb uusimast vanimani.)

IMAP INTERNALDATE

See on kõige tähtsam metaandmete väärtus mõistmaks, miks mõnel muutmisel pole nähtavat mõju. INTERNALDATE on IMAP-serveri poolel talletatud atribuut, mis on sõltumatu sõnumi sisust. Seda kasutab enamik meiliklienti kaustades meilide sorteerimiseks. Outlook kasutab seda. Gmail samuti. Apple Mail teeb seda enamikul juhtudel ka.

INTERNALDATE ei ole sõnumis. See on serveri andmebaasis. Te ei saa seda muuta, redigeerides kettale salvestatud .eml-faili.

Mis tegelikult juhtub, kui muudate kohalikult

.eml-faili redigeerimine

Tehniliselt on .eml-fail tekstifail. Saate selle avada redaktoris, muuta rida Date: ja salvestada. Kui impordite selle faili tagasi kohalikku meiliklienti, võib kuvatav kuupäev muutuda, sõltuvalt kliendist.

Kuid see ei muuda järgmist:

• INTERNALDATE'i IMAP-serveril (jääb muutumatuks)
• Vahendusserverite lisatud Received: päiseid
• Kättetoimetamise logisid Google'il, Microsoftil või teie teenusepakkujal
• DKIM-allkirja, kui sõnumil see oli

Tulemus: teie kohalikel seadmetel näete võib-olla teistsugust kuupäeva. Exchange Online'iga ühendatud Outlookis või brauseri Gmailis ei ole midagi muutunud.

Süsteemikella muutmine

Mõned foorumid soovitavad muuta tööjaama kella, et "petta" meiliklienti. See ei tööta. Outlook ja Gmail ei loe saadud meilide kuupäevade kuvamiseks süsteemikella. Nad loevad INTERNALDATE'i serverist või sõnumi päiseid. Kohalik kell ei mängi selles protsessis mingit rolli.

Thunderbirdi kaudu manipuleerimine

Thunderbird pakub enamikust klientidest rohkem paindlikkust. Laienduste või profiili otsese manipuleerimise (mbox-failid, .msf-failid) abil üritavad mõned kuupäevade kuvamist muuta. See võib toimida Thunderbirdis endas POP3-režiimis kohalikult salvestatud meilide puhul. Kuid niipea, kui Thunderbird on IMAP-ühenduses, sünkroniseerib see serveriga uuesti. "Parandus" kaob järgmisel sünkroonimisel.

DKIM: nähtamatu tõke, mida keegi ei maini

Enamik alates 2018. aastast saadetud meilidest on allkirjastatud DKIM-iga (DomainKeys Identified Mail). DKIM-allkiri näeb päistes välja järgmiselt:

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...

Väli h= loetleb allkirjaga kaetud päised. Ülaltoodud näites on Date allkirjastatud. Kui muudate sõnumi päist Date:, nurjub DKIM-kontroll. Iga meiliserverit, iga kohtuekspertiisi tööriist suudab muutmise avastada allkirja ümberarvutamise teel.

See pole täiuslik kaitse (pahatahtlik saatja kontrollib oma DKIM-võtit ja saab allkirjastada mida iganes saatmise hetkel). Kuid juba saadud ja allkirjastatud meili puhul jätab päise Date: muutmine tuvastatava jälje.

Serverilogid: tegelik tõeallikas

Isegi kui õnnestuks muuta kõiki e-kirja nähtavaid metaandmeid (päised, INTERNALDATE, kõik), säilitavad teenusepakkujad oma logid.

Google Workspace logib iga sõnumi Admin Console'i auditilogi. Microsoft 365 teeb sama vastavusnäitajas (Purview). Need logid sisaldavad kättetoimetamise ajatempleid, olenemata sellest, mida kliendid kuvavad. Advokaat, juriidiline osakond või infoturbe meeskond saab need andmed kätte. Outlookis kuvatav kuupäev ei oma kohtuprotsessil ega turbeauditi käigus tõenduslikku jõudu.

Täpsustuseks: isegi domeenidelegatsiooniga postkastile juurdepääsuga administraator ei suuda neid logisid tagasiulatuvalt üle kirjutada. Need on kasutajate, isegi privilegeeritud kasutajate käeulatusest väljas.

Seaduslik juhtum: migratsioonijärgne parandamine

Olete just lõpetanud 150 postkasti migratsiooni kohapealsest Exchange'ist Microsoft 365-i. Järgmisel esmaspäeval hakkavad tikette tulema: "kõik minu vanad meilid on kuupäevastatud eelmisest reedest". Migratsioonipäevast.

See on hästi dokumenteeritud probleem, mis erineb täielikult sellest, mida just kirjeldasime. Siin ei ürita keegi midagi võltsida. Tegelikud algupärased kuupäevad on endiselt olemas, puutumatult, iga sõnumi päises Date:. Probleem on mujal: migratsioonitööriist (BitTitan MigrationWiz, CloudM, imapsync või mõni muu) on lisanud ahela algusesse Received: päise koos migratsioonikuupäevaga. Outlook, mis teatud kontekstides tugineb Received: uusimatele päistele pigem kui INTERNALDATE'ile, kuvab selle kuupäeva.

Sel juhul seisneb "parandamine" kooskõla taastamises selle vahel, mida sõnum ütleb (algupärane päis Date:, mis on endiselt alles), ja mida server arvab (INTERNALDATE, mis fikseeriti migratsiooni ajal). See pole võltsimine. See on taastamine.

Täpsemalt saab lugeda, miks valesti seadistatud migratsioon tekitab tuhandetele postkastidele probleeme. Ja just seda Redate.io lahendab.

Miks "tee ise" meetod mahus läbi kukub

Probleemist aru saamine on üks asi. Selle parandamine 40 000 meilil 150 postkastis ilma ühtegi kaotamata on hoopis midagi muud.

GitHub'ist või Stack Overflow'st leitud skriptid töötavad 20 testmeili peal. Toodangukeskkonnas tekivad probleemid põhjustel, mida skripti autor ette ei näinud:

• S/MIME-allkirjastatud või PGP-krüpteeritud meilid on struktuurilt sellised, mida ei saa käsitleda tavaliste sõnumitena
• Mitmeosalised sõnumid (multipart) mittestandardsete MIME-piiridega põhjustavad sõelumisvigu
• RFC 2047 järgi kodeeritud päised (mitte-ASCII märgid väljades From: või Subject:) purustavad lihtsama sõeluri
• Google'i ja Microsofti API-d rakendavad kiirusepiiranguid: kell 3 öösel 30 000-kirjalise töö ajal ei käsitleta viga 429 Too Many Requests, skript peatub ja keegi ei tea, kus see peatus
• Tagasipöördumise mehhanismi pole: kui töötlemise käigus sõnum rikutakse, pole võimalust tagasi minna

Redate.io säilitab iga algupärase e-kirja koopia nähtavas varunduskaustast 30 päeva jooksul. Iga parandus kontrollitakse individuaalselt. Analüüsipipeline käsitleb sadu tuntud migratsioonitööriistade signatuure ning kõiki erijuhtumeid, millega kodutehtud skript hakkama ei saaks.

Täpsemalt tööriistade kaupa: BitTitan MigrationWiz ja e-kirjade kuupäevad ning CloudM Migrate: valede kuupäevade parandamine.

Mis muutub, mis ei muutu kunagi

Erinevus on selge. Tabeli kolm esimest rida kirjeldavad pindmisi või tuvastatavaid muudatusi. Viimane kirjeldab seaduslikku metaandmete parandamist, mis on kooskõlas sõnumi algupärase sisuga, pärast migratsiooni, mis on toonud kaasa ebakõla.

Kui olete tabeli viimases reas kirjeldatud olukorras, pärast migratsiooni imapsync'iga, BitTitaniga, CloudM'iga või mõne muu tööriistaga, on Redate.io just selleks loodud.

Teie meilid kuvavad migratsioonikuupäeva tegelike kuupäevade asemel? Skanneerige oma postkastid tasuta Redate.io'ga ja vaadake täpselt, kui palju meile on mõjutatud, enne kui otsustate.