Email dátumának módosítása: lehetséges és kimutatható

Email dátumának módosítása: miről is van szó pontosan?

Ez a kérdés rendszeresen visszatér rendszeradminisztrátori fórumokon és MSP-s Slack-csoportokban: módosítható-e egy email dátuma az elküldés után? A rövid válasz: igen, technikailag. De a teljes válasz jóval kevésbé megnyugtató annak, aki ezt kétes célokra szeretné felhasználni.

Egy email nem egyetlen, egybefüggő fájl. Szöveges fejlécek gyűjteménye, amelyet az üzenettörzs követ. Ezek a fejlécek közül több is dátuminformációt tartalmaz. És némelyiket könnyebb módosítani, mint a többit.

Minden emailben három dátumozási réteg él egymás mellett:

• A Date: fejléc (RFC 2822), amelyet a levelezőprogram az elküldés pillanatában ír be
• A Received: fejlécek, amelyeket minden közvetítő szerver fűz hozzá az üzenethez
• Az IMAP INTERNALDATE, egy szerveroldalon tárolt metaadat, amely független az üzenet tartalmától

Mindhárom réteg módosítható. Egyik sem nyom nélkül.

A Date: fejléc módosítása: a legkézenfekvőbb manipuláció

A Date: fejléc egyszerű szöveg a .eml fájlban. Technikailag bármely hexadecimális szerkesztő vagy Python-szkript néhány másodperc alatt átírhatja. Ha valaha is megnézte egy email nyers fejléceit a Gmailben (a kis "Eredeti megjelenítése" menüpont), tudja, hogy ez bárki számára olvasható.

Mi a probléma? 2004 óta a levelezőszerverek túlnyomó többsége DKIM (DomainKeys Identified Mail) aláírással látja el a kimenő emaileket. Ez a kriptográfiai aláírás kifejezetten lefedi a legfontosabb fejléceket: a Date:, From:, Subject: mezőket és az üzenettörzset is. Az aláírást a DKIM-Signature: fejlécben tárolják.

Ha az aláírás után módosítja a Date: mezőt, a DKIM-ellenőrzés automatikusan érvénytelen lesz. Bármely fogadó szerver ellenőrizheti az aláírást úgy, hogy lekéri a nyilvános kulcsot a feladó domain DNS-éből. Ha az aláírás nem egyezik, az üzenetet megváltoztatottnak jelöli. A Gmail, az Outlook.com és az összes nagy szolgáltató ezt az ellenőrzést automatikusan elvégzi.

(Ha egyébként szeretne konkrétan látni egy DKIM-aláírást, nyissa meg egy Gmailből vagy Office 365-ből érkezett email nyers fejléceit: ott talál egy DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... kezdetű sort, amely véletlenszerű zajnak tűnik, valójában azonban az egész üzenet kriptográfiai hash-e.)

Eredmény: ha valaki módosítja a Date: fejlécet egy DKIM-aláírt emailben, feltöri a pecsétet. A módosítás látható minden olyan adminisztrátor számára, aki tudja, hol kell keresni.

A Received: fejlécek átírása: nehezen hamisítható lánc

A Received: fejlécek nyomon követik, milyen úton jutott el az email a feladótól a címzettig. Minden SMTP-szerver, amelyen átmegy az üzenet, hozzáfűzi a sajátját, a nevével, IP-címével és időbélyegzőjével együtt. Egy két-három kiszolgálón átmenő email ennek megfelelően két-három egymásra rakott Received: fejlécet tartalmaz.

Módosíthatók-e ezek? Technikailag igen, a saját másolatán. De itt van a csapda: a címzettnek is van másolata. Az ő szervere a legutolsóként fűzte hozzá a saját Received: fejlécét. Ez a fejléc a címzett ellenőrzése alatt áll, nem a feladóéban. Kívülről hamisíthatatlan.

A lánc koherenciája ellenőrizhető. Ha az egymást követő Received: fejlécek időbélyegei inkoherensek (például egy közbenső kiszolgáló a feladó elküldése előtt kapta volna meg az üzenetet), az azonnal gyanús. Az olyan email-forensikai eszközök, mint az MXToolbox, vagy a biztonsági csapatok belső eszközei, pontosan ezt ellenőrzik.

Igazából nem teljesen pontos azt mondani, hogy a Received: fejlécek teljesen hamisíthatatlanok: egy saját levelezési infrastruktúrát üzemeltető támadó hihető fejléceket tud gyártani az általa ellenőrzött kiszolgálókhoz. De az utolsó láncszemet, vagyis a címzett szerverét soha nem irányíthatja.

Az IMAP INTERNALDATE: a legtechnikusabb eset

Az INTERNALDATE egy IMAP-metaadat, amelyet a szerver tárol. Nem fejléc az üzenetben: egy érték, amelyet a szerver belső adatbázisában rendel az üzenethez. A legtöbb levelezőprogram ezt az értéket használja az üzenetek beérkező mappában való rendezéséhez.

Az IMAP APPEND parancs lehetővé teszi, hogy egy üzenetet egy szerverre töltsenek fel, expliciten megadott INTERNALDATE-tel. Ez a protokoll egy teljesen legitim funkciója, amelyet az RFC 3501 dokumentál. A migrációs eszközök folyamatosan használják: az imapsync, a BitTitan MigrationWiz, a CloudM, a GSMMO... mind megadott INTERNALDATE-tel töltenek fel emaileket a célszerverre.

Elméletileg valaki, akinek IMAP-hozzáférése van a saját postafiókjához, bármilyen INTERNALDATE-tel feltölthet egy emailt. De ez a manipuláció nem módosítja az üzenet fejléceit. Az eredeti Date: érintetlen marad, a Received: fejlécek érintetlenek maradnak, a DKIM-aláírás érintetlen marad. Csak a szerveroldalon lévő rendezési metaadat változik.

Egy szakértő, aki megvizsgálja a nyers üzenetet, azonnal észreveszi az INTERNALDATE és a Date: közötti eltérést. Ha az üzenetet DKIM írta alá, az eredeti dátum kriptográfiailag igazolt.

A Message-ID: nehezen hamisítható ujjlenyomat

Minden email egyedi azonosítót kap, a Message-ID: fejlécet. Ezt az azonosítót a feladó SMTP-szervere az elküldés pillanatában generálja, általában egy időbélyeg, egy véletlenszerű azonosító és a szerver doménneve kombinálásával.

Egy tipikus Message-ID így néz ki: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Az időbélyeg sokszor közvetlenül az azonosítóba van kódolva. Ha valaki módosítja az email dátumát, de benne hagyja az összeférhetetlen időbélyeget tartalmazó Message-ID-t, azonnal szembeötlő inkoherenciát hoz létre.

Ráadásul a Message-ID-ket a nagy levelezőrendszerek indexelik. A Google, a Microsoft és más szereplők naplókat vezetnek, amelyek alapján vissza lehet keresni, hogy egy üzenet mikor forgott valóban az infrastruktúrájukon. Jogi vagy forensikai kontextusban ezek a naplók bírósági eljárás keretében elérhetők.

A gyakorlatban: ki tudja kimutatni a manipulációs kísérletet?

Tegyük fel a kérdést konkrétan. Kap egy emailt, amelyről gyanítja, hogy a dátumát módosították. Mit tehet egy IT-adminisztrátor vagy egy minimális technikai háttérrel rendelkező ügyvéd?

• DKIM-ellenőrzés: a Gmailben az "Eredeti megjelenítése" menü közvetlenül az oldal tetején mutatja a DKIM-ellenőrzés eredményét. A "PASS" az üzenet integritását igazolja az elküldés óta. A "FAIL" vagy "SOFTFAIL" módosításra utal.
• Fejlécelemzés: az MXToolbox Header Analyzer vagy a Google Admin Toolbox eszközök automatikusan elemzik a Received: fejlécek láncát, és jelzik az időbeli inkoherenciákat.
• Message-ID / Date koherencia: egy elemző összehasonlíthatja a Message-ID-be kódolt időbélyeget a deklarált Date: értékével.
• Szernaplók: ha az email átment egy olyan szerveren, amelynek Ön az adminisztrátora, az SMTP-naplók tartalmazzák az üzenet tényleges elfogadásának dátumát és időpontját, függetlenül bármely fejléctől.

Szóval az észlelési eszközök elérhetők, ingyenesek, és nem igényelnek haladó forensikai szaktudást. Egy kicsit kíváncsi IT-adminisztrátor két percen belül ellenőrizheti egy email integritását.

Az egyetlen legitim tömeges dátummódosítási eset: az IMAP-migráció

Van egy forgatókönyv, ahol több százezer email helytelen dátummal végez, minden rosszindulatú szándék nélkül: az IMAP-migráció.

Képzelje el: éppen befejezte 150 Exchange-postafiók Google Workspace-re való migrálását. Hétfő reggel jönnek a bejelentések. A felhasználók azt jelzik, hogy minden régi emailjük ugyanazon a dátumon jelenik meg, a migrációs hétvégéén. A beérkező mappájuk olvashatatlan.

Ami történt, az dokumentált és megjósolható: a migrációs eszköz (BitTitan, CloudM, imapsync, mindegy melyik) IMAP APPEND paranccsal töltötte fel az emaileket a Google Workspace-re. A migráció dátumát adta meg INTERNALDATE-ként, nem az email eredeti dátumát. Eredmény: az Outlook, amely alapértelmezés szerint INTERNALDATE szerint rendez, minden üzenetnél a migráció dátumát jeleníti meg. A Miért mutatnak rossz dátumot az emailek migráció után? cikk ezt a mechanizmust részletesen magyarázza el.

Az eredeti Date: fejléc minden üzenetben érintetlen. A DKIM-aláírások érintetlenek. A tartalom nem változott. Kizárólag a szerveroldalon lévő INTERNALDATE helytelen.

Ez a probléma a BitTitan MigrationWiz-t, a CloudM Migrate-et, az imapsynct, a GSMMO-t és minden olyan eszközt érinti, amely IMAP APPEND-et használ az INTERNALDATE megfelelő megőrzése nélkül. A BitTitan-nak szentelt cikk lefedi ennek az eszköznek a sajátosságait. Az email-migrációs ellenőrzőlista felsorolja a migráció előtt és után ellenőrizendő pontokat, hogy elkerüljük az ilyen típusú problémákat.

A különbség a javítás és a hamisítás között

A Redate.io által elvégzett javítás az ellentéte egy hamisítási kísérletnek. A saját fejlesztésű javítómotor elemzi az egyes üzenetek fejlécláncolatát, azonosítja a Date: fejlécbe (RFC 2822) kódolt eredeti dátumot, amely soha nem változott, és korrigálja a dátum-metaadatokat, hogy összhangba hozza azokat ezzel az üzenetben már eleve jelenlévő, hiteles információval.

A Date: fejléc az igazság forrása. A feladó levelezőprogramja írta be az elküldés pillanatában. A DKIM-aláírás lefedi. A Redate.io nem módosítja. Ami javításra kerül, az a migrációs eszköz által okozott eltérés, nem az eredeti dátum.

47 000 email javítása egy sikertelen migráció után egyetlen elveszett üzenet nélkül, a vitaszálak megtörése nélkül, a mellékletek megrongálása nélkül, anélkül hogy hajnali 3-kor 429-es hibát váltson ki a Google API-n: ez egy többlépéses elemzési pipeline, amely kezeli a határeseteket (S/MIME, PGP, nem ASCII kódolások RFC 2047 szerint, összetett multipart struktúrák). Egy ötsorosszkript nem élné túl az első éles postafiókot. A Javíthatók-e az email dátumok migráció után? cikk részletezi, miért kockázatos a barkács megközelítés valós mennyiségek esetén.

A Redate.io ingyenesen átvizsgálja a postafiókokat, azonosítja a helytelen dátumú emaileket, és egy olyan validációs pipeline-on keresztül javítja azokat, amely minden üzenetet egyenként ellenőriz. Az eredeti példányokat egy látható biztonsági mentési mappában tárolja 30 napig. Ha valami rosszul sülne el, a visszaállítás lehetséges.

A migráció eltolta az emailjei dátumait? Indítson el egy ingyenes szkennelést a Redate.io-n, hogy felmérje a probléma mértékét, mielőtt döntést hozna.