Fogadott email dátumának módosítása: tény vagy mítosz?

A kérdés, amit mindenki feltesz (és miért rejt két teljesen különböző helyzetet)

Gépelje be a Google-ba: „fogadott email dátumának módosítása". Tucatnyi Microsoft Q&A fórumszál, Reddit-téma, Quora-kérdés jelenik meg. A keresési szándék egyértelmű, de a mögötte lévő okok radikálisan eltérnek attól függően, ki teszi fel a kérdést.

Vannak, akik utólag akarnak dátumot hamisítani, olyan okokból, amelyeket inkább nem részletezünk. És vannak IT-adminisztrátorok, akik egy IMAP-migráció után látják, hogy az összes emailjük ugyanazt a napot mutatja (a migráció dátumát), és egyszerűen vissza szeretnék kapni a valódi dátumokat. A két helyzet semmi köze egymáshoz, mégis ugyanazzal a keresési kifejezéssel keresnek rájuk.

Ez a cikk mindkét esetre válaszol. Spoiler: az első esetben a módosítás nem igazán végrehajtható észrevétlenül. A másodikban teljesen jogszerű, és pontosan ezt végzi el a Redate.io.

Először is: mi az email „dátuma"?

Egy emailnek nincs egyetlen dátuma. Több dátuma van, különböző helyeken tárolva, különböző entitások által kezelve.

A Date: fejléc (RFC 2822)

Ez az a dátum, amelyet a feladó levelezőprogramja ír bele az üzenetbe a küldés pillanatában. A nyers fejlécekben így jelenik meg:

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

Ez a fejléc az üzenet törzsének része. Technikailag módosítható, ha hozzáfér a nyers fájlhoz. De a „technikailag" itt a kulcsszó.

A Received: fejlécek

Minden levelezőszerver, amelyen az email áthalad, hozzáadja a saját Received: fejlécét egy időbélyeggel. Ezek a fejlécek egy kronológiai láncot alkotnak, a feladó szerverétől egészen a beérkező postafiókig. (Ha valaha is megpróbálta olvasni egy email nyers fejléceit, tudja, hogy az nem éppen strandolvasmány. Néhány tucat sor technikai metaadat, a legújabbtól a legrégebbi felé haladva.)

Az IMAP INTERNALDATE

Ez a legfontosabb metaadat ahhoz, hogy megértsük, miért nem látható egyes módosítások hatása. Az INTERNALDATE az IMAP-szerver oldalán tárolt attribútum, az üzenet tartalmától teljesen függetlenül. A legtöbb levelezőprogram ezt használja az emailek dossziékban való rendezéséhez. Az Outlook is. A Gmail is. Az Apple Mail is, az esetek túlnyomó részében.

Az INTERNALDATE nem az üzenetben van. A szerver adatbázisában van. Nem módosítható úgy, hogy a merevlemezen szerkeszt egy .eml fájlt.

Mi történik valójában, ha helyben módosít

.eml fájl szerkesztése

Technikailag egy .eml fájl szöveges fájl. Megnyithatja szerkesztőben, átírhatja a Date: sort, elmentheti. Ha ezt a fájlt visszaimportálja egy helyi levelezőprogramba, a megjelenített dátum változhat, az adott programtól függően.

De íme, ami nem változik:

• Az IMAP-szerveren tárolt INTERNALDATE (érintetlen marad)
• A közvetítő szerverek által hozzáadott Received: fejlécek
• A kézbesítési naplók a Google-nél, a Microsoftnál vagy az email-szolgáltatónál
• A DKIM-aláírás, ha az üzeneten volt ilyen

Eredmény: a saját gépén talán más dátumot lát. Az Exchange Online-hoz csatlakoztatott Outlookban, vagy böngészőben megnyitott Gmailben semmi sem változott.

A rendszeróra módosítása

Néhány fórumon felmerül az ötlet, hogy módosítsák a munkaállomás óráját, hogy „becsapják" a levelezőprogramot. Ez nem működik. Az Outlook és a Gmail nem a rendszerórát olvassa a fogadott emailek dátumának megjelenítésekor. Az INTERNALDATE-et olvassa a szerverről, vagy az üzenet fejléceit. A helyi óra egyáltalán nem játszik szerepet ebben a folyamatban.

Módosítás Thunderbird segítségével

A Thunderbird rugalmasabb a legtöbb levelezőprogramnál. Bővítményekkel vagy a profil közvetlen szerkesztésével (mbox fájlok, .msf fájlok) sokan próbálják módosítani a dátumok megjelenítését. Ez működhet magában a Thunderbirdben, POP3 módban helyben tárolt emaileknél. De amint a Thunderbird IMAP-kapcsolatban van, újraszinkronizál a szerverrel. A „javítás" eltűnik a következő szinkronizáláskor.

DKIM: a láthatatlan gát, amelyről senki sem beszél

A 2018 óta küldött emailek többsége DKIM-aláírással (DomainKeys Identified Mail) van ellátva. Egy DKIM-aláírás így néz ki a fejlécekben:

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

A h= mező felsorolja az aláírás által lefedett fejléceket. A fenti példában a Date is alá van írva. Ha módosítja az üzenet Date: fejlécét, a DKIM-ellenőrzés meghiúsul. Bármely levelezőszerver, bármely igazságügyi elemzőeszköz képes felismerni a módosítást az aláírás újraszámításával.

Ez nem tökéletes védelem (egy rosszindulatú feladó kezeli a saját DKIM-kulcsát, és aláírhat bármit a küldés pillanatában). De egy már megkapott, aláírt emailnél a Date: fejléc módosítása kimutatható nyomot hagy.

A szerverlogs: a valódi igazságforrás

Még ha sikerülne is módosítani az email összes látható metaadatát (fejlécek, INTERNALDATE, minden), a szolgáltatók megőrzik a saját naplóikat.

A Google Workspace minden üzenetet rögzít az Admin Console auditnaplóiban. A Microsoft 365 ugyanezt teszi a Compliance Centerben (Purview). Ezek a naplók tartalmazzák a kézbesítés időbélyegeit, függetlenül attól, hogy mit mutatnak a levelezőprogramok. Egy ügyvéd, jogi osztály vagy informatikai biztonsági csapat le tudja kérni ezeket az adatokat. Az Outlookban megjelenő dátum nem hiteles bíróság előtt vagy biztonsági auditkor.

Pontosabban fogalmazva: még egy tartományi delegálással rendelkező adminisztrátor sem képes visszamenőlegesen felülírni ezeket a naplókat. Ezek elérhetetlen az összes felhasználó számára, még a kiemelt jogosultságúak számára is.

A jogszerű eset: migrációt követő javítás

Ön just befejezett egy 150 postafiókos migrációt helyi Exchange-ről Microsoft 365-re. A következő hétfőn megérkeznek a ticketek: „minden régi emailem a múlt pénteki dátumot mutatja". A migráció dátumát.

Ez egy jól dokumentált probléma, és teljesen más, mint amit az imént leírtunk. Itt senki nem akar semmit hamisítani. A valódi eredeti dátumok még mindig ott vannak, érintetlenül, minden egyes üzenet Date: fejlécében. A probléma máshonnan ered: a migrációs eszköz (BitTitan MigrationWiz, CloudM, imapsync vagy más) egy Received: fejlécet szúrt be a migráció dátumával a lánc elejére. Az Outlook, amely bizonyos kontextusokban a legújabb Received: fejléceket részesíti előnyben az INTERNALDATE-del szemben, ezt a dátumot jeleníti meg helyette.

Ebben az esetben a „javítás" azt jelenti, hogy helyreállítjuk az összhangot az üzenet tartalma (az eredeti Date: fejléc, amely még mindig ott van) és a szerver értelmezése (az INTERNALDATE, amelyet a migráció pillanatában állítottak be) között. Ez nem hamisítás. Ez helyreállítás.

Pontosan ezt a jelenséget okozza egy rosszul konfigurált migráció ezernyi postafiókban. És ezt oldja meg a Redate.io.

Miért vallanak kudarcot az egyéni megoldások nagyobb méretekben

A probléma megértése egy dolog. 150 postafiókban, 40 000 emailen elvégezni a javítást egyetlen üzenet elvesztése nélkül, az egészen más.

A GitHubon vagy a Stack Overflow-n talált szkriptek 20 tesztemailon működnek. Éles környezetben problémákba ütköznek olyan okokból, amelyeket a szkript szerzője nem látott előre:

• Az S/MIME-mel aláírt vagy PGP-vel titkosított emailek olyan szerkezetűek, amelyek nem kezelhetők ugyanúgy, mint a hétköznapi üzenetek
• A nem szabványos MIME-határokkal rendelkező többrészes üzenetek elemzési hibákat okoznak
• Az RFC 2047 szerint kódolt fejlécek (nem ASCII karakterek a From: vagy Subject: mezőkben) összetörik a naiv parsereket
• A Google és a Microsoft API-k sebességkorlátozást alkalmaznak (rate limiting): hajnali 3-kor, egy 30 000 emailes köteg közben, a 429 Too Many Requests hiba nincs kezelve, a szkript leáll, és senki nem tudja, hol állt meg
• Nincs visszaállítási mechanizmus: ha feldolgozás közben egy üzenet sérül, nincs mód visszalépni

A Redate.io minden eredeti email másolatát megőrzi egy látható biztonsági mentési mappában 30 napig. Minden javítást egyenként ellenőriz. Az elemzési folyamat több száz ismert migrációs eszköz aláírását kezeli, beleértve az összes határesetet, amelyekkel egy házi szkript nem boldogulna.

Ha részletesebb tájékoztatást szeretne az egyes eszközökre vonatkozó sajátosságokról, olvassa el: BitTitan MigrationWiz és az email dátumok, vagy CloudM Migrate: hibás email dátumok javítása.

Mi változik, és mi nem változhat soha

A különbség egyértelmű. A táblázat első három sora felszínes vagy kimutatható módosításokat ír le. Az utolsó sor jogszerű metaadat-javítást ír le, amely összhangba hozza az üzenet eredeti tartalmát azzal, amit a szerver az eltérést okozó migráció után nyilvántart.

Ha az Ön helyzete a táblázat utolsó sorára illik, akár imapsync, BitTitan, CloudM vagy más eszköz által végzett migráció után, a Redate.io pontosan erre a célra készült.

Az emailjei a migráció dátumát mutatják a valódi dátumok helyett? Vizsgálja meg ingyenesen a postafiókjait a Redate.io segítségével, és derítse ki pontosan, hány emailt érint a probléma, mielőtt döntést hoz.