E-kirja kuupäeva muutmine: tehnilised piirangud

Meilil on kolm "kuupäeva". Mitte üks.

Kui inimesed räägivad "e-kirja vastuvõtukuupäeva muutmisest", kujutavad nad tavaliselt ette mingi välja muutmist, nagu muutaks Windowsis faili loomiskuupäeva. Tegelikkus on veidi keerulisem. Igal meilil on tegelikult kolm eraldiseisvat kuupäevakihti, igaühel oma reeglid, oma "valvurid" ja oma tagajärjed, kui neisse puututakse.

Nende kolme kihi mõistmine on võti selleks, et aru saada, miks mõned parandused on tehniliselt ohutud, teised aga võimatud või koheselt falsifikatsioonina tuvastatavad.

Kiht 1: IMAP INTERNALDATE

INTERNALDATE on serveri poolel salvestatud metaandmed, väljaspool kirja enda sisu. See ei ole meili osa. IMAP-server määrab selle väärtuse ja just seda kasutavad enamik meilirakendusi kirjade loendis sortimiseks.

Outlook kuvab vaikimisi sõnumeid INTERNALDATE järgi sorteerituna. Gmail samuti, teatud kontekstides. Seega, kui INTERNALDATE on vale, näivad kõik teie meilid liidesesse sama kuupäevaga, olenemata sellest, mida kirja sisemised päised ütlevad.

INTERNALDATE määratakse hetkel, mil sõnum serverisse üles laaditakse. IMAP-protokolli kaudu saab seda "muuta" ainult kaudselt: tuleb kasutada käsku APPEND, et laadida sõnumist uus koopia soovitud kuupäevaga. Käsku SETINTERNALDATE IMAP-protokollis ei eksisteeri. See detail tuleb mängu veidi hiljem.

Kiht 2: päis Date: (RFC 2822)

See on Date: väli kirja töötlemata päistes. Meilirakendus määrab selle saatmise hetkel ja see reisib koos sõnumiga serverist serverisse. See on saatja deklareeritud saatmiskuupäev.

(Muide, kui te pole kunagi vaadanud kirja töötlemata päiseid, on see üsna huvitav lugemine. Igal sõnumil on umbes kakskümmend tehnilist rida, mida 99% inimestest pole kunagi näinud.)

Tehniliselt ei takista miski saatmast meili tagantjärele- või ettepoole dateeritud Date: väljaga. SMTP-serverid seda välja ei valideeri. Aga sihtserverid märgivad tegeliku saabumisaja Received: päistesse, mis loob koheselt ebakõla, mida iga meilirakendus või analüüsitööriist kohe näeb.

Kiht 3: virnastatud Received: päised

Iga kord, kui SMTP-server sõnumit edasi saadab, lisab ta virna tippu uue Received: päise koos ajatempliga. Kolme serveri kaudu liikunud meilil on kolm Received: päist. Neid loetakse alt üles: kõige vanem on all, kõige uuem ülal.

Just siin tekitavad migratsioonivahendid probleemi. Kui BitTitan MigrationWiz, CloudM, imapsync või GSMMO migreerivad kirja, laadivad nad selle uuele serverile IMAP-i kaudu üles. See laadimine genereerib uue Received: päise, mis on ajatemplitud migratsiooni toimumise hetkele. Tulemus: teie postkasti kõige vanem kiri, näiteks 2019. aastast pärit meil, saab Received: päise, mille kuupäev on november 2024. Ja kuna mõned meilirakendused (Outlook eelkõige) kasutavad kuvamisel kõige uuemat Received: päist...

Ongi probleem. 15 000 kirja kuvavad kõik sama migratsioonikuupäeva.

Kas neid kuupäevi saab tegelikult "muuta"?

Tehniliselt jah, INTERNALDATE puhul (teatud piirangutega). Tehniliselt võimalik, kuid kasutu Date: puhul. Ja Received: päiste puhul tasub pikemalt peatuda.

Received: päise ümberkiijutamine on triviaalne. Ja koheselt tuvastatav.

Received: päis on lihtsalt tekstirida kirjas. Seda saab redigeerida nagu iga tekstifaili. See ongi täpselt nii lihtne, kui tundub.

Aga siin on see, mis juhtub edasi.

Esimene probleem: DKIM. DKIM-allkiri (DomainKeys Identified Mail) arvutatakse sõnumi päiste kogumi põhjal, millesse kuuluvad mõnikord ka Received: päised. Allkirjastatud päise muutmine kehtetustab allkirja. Iga sihtsever, mis DKIM-i kontrollib, näeb koheselt, et sõnumit on muudetud. See pole peen falsifikatsioon, see on alarm.

Teine probleem: sisemised identifikaatorid. Kaasaegsed meiliserverid (Google Workspace, Microsoft 365) annavad igale sõnumile unikaalse kasvava sisemise identifikaatori. Need identifikaatorid on seotud INTERNALDATE'i ja vastuvõtujärjekorraga. Received: päise muutmine ilma nende identifikaatoritega kooskõlastamata loob ebakõlasid, mida auditeerimistööriistad probleemideta tuvastavad.

Kolmas, praktilisem probleem: isegi kui muudate sõnumi sisus Received: päist, pole te puutunud INTERNALDATE'i, mis jääb endiselt IMAP-i laadimise ajaks. Meilirakendus kuvab sortimiseks jätkuvalt valet kuupäeva. Olete sõnumit muutnud ilma tulemusteta.

Lühidalt. Received: päiste ümberkiijutamine kuupäeva pahatahtlikuks võltsimiseks: tehniliselt triviaalne, eksperdi poolt mõne sekundiga tuvastatav. See pole tõsine tee.

Date: päis: mineviku muutmine paberil

Sama loogika kehtib Date: puhul. Seda saab kirja sisusse muuta. Aga vahendusserverite autentitud Received: päised jäävad puutumata ja räägivad teist lugu. Ajaline ahel on ebajärjekindel. Iga analüütik või kohus, kes neid välju võrdleb, näeb seda koheselt.

Täpsuse huvides: see ei takista mõnel meilirakendusest muudetud Date: kuvamast, kui neile esitatakse otse .eml-fail. Aga live-meilisserveri kontekstis, autentimise ja logidega, on muutmine läbipaistev.

IMAP-migratsioon: ainus kontekst, kus kuupäevade parandamine on põhjendatud

On üks ja ainult üks juhtum, kus kirja vastuvõtukuupäeva muutmine pole mitte ainult võimalik, vaid ka tehniliselt õigustatud: halvasti teostatud IMAP-migratsiooni põhjustatud kahjude parandamine.

Konkreetne olukord. Olete just lõpetanud 80 Exchange'i postkasti migratsiooni Microsoft 365-i. Migratsioon lõppes reede õhtul. Esmaspäeva hommikul hakkavad saabuma esimesed tugipiletid: "Kõigil minu meilidel on sama kuupäev", "Ma ei leia eelmise aasta kirja üles", "Minu kirjavahetus selle kliendiga on täiesti katki". Teil on 80 blokeeritud kasutajat ja juht, kes ootab vastust.

Selles kontekstis on probleem dokumenteeritud, tuvastatav ja selle põhjus selge: migratsioonitööriist lisas Received: päise, mis on dateeritud migratsioonipäevaga, ja mõned meilirakendused kasutavad seda uut päist kuvamiskuupäevana. Algne Date: päis on aga igas kirjas puutumatu. Seda pole kunagi muudetud. See sisaldab endiselt algset, korrektset saatmiskuupäeva.

Parandamine pole seega võltsimine, see on taastamine. Lähtutakse tõelistest andmetest (algne Date:) ja rekonstrueeritakse kooskõlalised metaandmed. See on põhimõtteliselt erinev sellest, kui üritataks 2024. aasta kirja esitleda 2019. aasta kirjana.

Konkreetsete tööriistade mehhanismide kohta lähemalt, need juhendid käsitlevad praktilisi juhtumeid: BitTitani kuupäevade parandamine Microsoft 365-s, CloudM kuupäevade parandamine Outlookis või imapsync kuupäevade parandamine Google Workspace'is.

Miks ise skripti kirjutamine on riskantne

Põhiloogika on kättesaadav. Iga IT-admin, kes on IMAP-foorumitel aega veetnud, suudab üldise lähenemisviisi rekonstrueerida. See pole probleem.

Probleem on lõhe skripti vahel, mis töötab 50 testimiskirja peal, ja skripti vahel, mis töötleb 40 000 kirja tootmiskeskkonnas ilma ühtegi kirja kaotamata, ilma ühtegi manust rikkumata ja ilma ühtegi vestluslõime katkestamata.

Mõned konkreetsed juhtumid, mida kodused skriptid tavaliselt ei käsitle:

• S/MIME-allkirjastatud kirjad: allkiri katab sisu ja päised. Sõnumi struktuuri igasugune muutmine kehtetustab allkirja. Kohmakalt parandatud allkirjastatud kiri jõuab adressaatideni teatega "allkiri kehtetu".
• PGP-krüpteeritud sõnumid: sama probleemide perekond, potentsiaalselt hullemate tagajärgedega sõltuvalt rakendusest.
• Mitte-ASCII kodeeringud päistes: RFC 2047 kirjeldab erimärkide kodeerimist päistes. Skript, mis töötleb päiseid neid juhtumeid arvestamata, rikub vaikselt e-kirjade teemaridu, mis sisaldavad täpitähti, jaapanikeelseid märke või araabia nimesid.
• API mahupiirangud: Google Workspace ja Microsoft 365 rakendavad agressiivseid piiranguid. Kell 3 öösel käivitatav 10 000 kirja pakett, mis põrkub vastu 429 Too Many Requests viga ilma eksponentsiaalse taandumise haldamiseta, jätab pooled postkastid poolikult parandatuks.
• Rikutud MIME-piirid: manustega multipart-sõnumitel on täpsed MIME-piirid. Nende vale regenereerimine muudab manused loetamatuks.

Ja küsimus, mida ükski kodune skript ei lahenda: kuidas kontrollida, et iga parandatud kiri on terviklik? Skript, mis muudab 40 000 sõnumit ilma individuaalse kontrollita, on hasartmäng. Hasartmäng andmetega, mida kasutajad peavad sageli asendamatuks.

Artikkel saadaolevate võimaluste kohta kuupäevade parandamiseks pärast migratsiooni käsitleb erinevaid lähenemisviise koos nende piirangutega.

Mida Redate.io selles kontekstis teeb

Redate.io on loodud spetsiaalselt just selleks otstarbeks: parandada IMAP-migratsiooni rikutud kuupäevi, suuremas mahus, ilma sõnumite terviklikkust ohustamata.

Teenus ühendub otse mõjutatud postkastidega (Google Workspace domeenidelegatsiooniga, Microsoft 365 Azure AD kaudu või otse IMAP-i kaudu), skannib tasuta väärate kuupäevadega sõnumeid, seejärel rakendab patenteeritud paranduspipeline'i, mis käsitleb eespool kirjeldatud servajuhtumeid. Iga kiri kontrollitakse pärast parandamist individuaalselt. Originaalid jäävad nähtavasse varunduskausta 30 päevaks.

Mustrite tuvastamine hõlmab sadu tuntud migratsioonivahendite allkirju: BitTitan MigrationWiz, CloudM, imapsync, GSMMO ja nende variandid. Tuvastamine on täpne: Redate.io ei puutu kirjadesse, mille kuupäev on korrektne.

Hinnamudel on lihtne: ühekordne makse postkasti kohta, ilma tellimuseta. Diagnostikaskannimine on tasuta, mis võimaldab hinnata kahjude ulatust enne otsuse tegemist.

Kui haldate selle probleemiga mõjutatud postkaste, see artikkel Outlooki valede kuupäevade kohta pärast migratsiooni kirjeldab kõige levinumaid sümptomeid ja nende eristamist muudest põhjustest.

Valmis mõõtma probleemi ulatust oma postkastides? Käivitage Redate.io-s tasuta skannimine ja vaadake täpselt, mitu kirja on mõjutatud, enne igasugust parandamist.