Fogadott email dátumának módosítása: technikai korlátok

Egy emailnek három "dátuma" van. Nem egy.

Amikor valaki a fogadott email dátumának módosításáról beszél, a legtöbben arra gondolnak, hogy egyszerűen megváltoztatnak egy mezőt valahol, mint ahogy Windows alatt egy fájl létrehozási dátumát módosítanák. A valóság ennél összetettebb. Minden email valójában három különálló dátumréteget hordoz, mindegyiknek saját szabályaival, saját korlátaival, és saját következményeivel, ha hozzányúlunk.

Ha megértjük ezt a három réteget, megértjük azt is, hogy bizonyos javítások miért technikailag indokoltak, mások viszont miért lehetetlenek, vagy miért mutathatók ki azonnal hamisításként.

1. réteg: az IMAP INTERNALDATE

Az INTERNALDATE egy szerveroldalon tárolt metaadat, amely magán az üzeneten kívül létezik. Nem része az email tartalmának. Az IMAP-szerver állítja be, és a legtöbb levelezőprogram ezt használja az emailek listázáshoz és rendezéshez.

Az Outlook például alapértelmezés szerint INTERNALDATE szerint rendezi az üzeneteket. A Gmail is, bizonyos helyzetekben. Ha tehát az INTERNALDATE hibás, az összes email ugyanazt a dátumot mutatja a felületen, függetlenül attól, mit mondanak az üzenet belső fejlécei.

Az INTERNALDATE akkor kerül beállításra, amikor az üzenetet letétbe helyezik a szerveren. Az IMAP-protokollon keresztül az egyetlen módja "módosítani" közvetett: az APPEND paranccsal kell feltölteni az üzenet egy új példányát a kívánt dátummal. Nincs IMAP SETINTERNALDATE parancs. Ez a részlet hamarosan fontossá válik.

2. réteg: a Date: fejléc (RFC 2822)

Ez a Date: mező az üzenet nyers fejléceiben. A levelezőprogram állítja be küldéskor, és az üzenettel együtt utazik szerverről szerverre. Ez az a dátum, amelyet a feladó küldési időpontként deklarált.

(Ha egyébként még sohasem nézte meg egy email nyers fejléceit, elég különös olvasmány. Minden üzenet kb. húsz sor technikai információt cipel magával, amelyet a felhasználók 99%-a soha nem látott.)

Technikailag semmi sem akadályozza meg, hogy valaki visszadátumozott vagy előre dátumozott Date: fejléccel küldjön emailt. Az SMTP-szerverek nem ellenőrzik ezt a mezőt. A fogadó szerverek viszont rögzítik a tényleges érkezési időt a Received: fejlécekben, ami azonnal látható következetlenséget okoz bármely levelezőprogram vagy elemzőeszköz számára.

3. réteg: a halmozott Received: fejlécek

Minden alkalommal, amikor egy SMTP-szerver továbbít egy üzenetet, egy Received: fejlécet ad a verem tetejére, időbélyeggel együtt. Egy három szerveren átment email három Received: fejlécet tartalmaz. Alulról felfelé olvasandók: a legrégebbi alul van, a legújabb felül.

Pontosan itt keletkezik a migrációs eszközök okozta probléma. Amikor a BitTitan MigrationWiz, a CloudM, az imapsync vagy a GSMMO migrál egy emailt, IMAP-on keresztül feltölti az új szerverre. Ez a feltöltés egy új Received: bejegyzést generál a migráció időpontjával. Eredmény: a postafiókod legrégebbi emailje, egy 2019-es üzenet, 2024 novemberi Received: fejléccel rendelkezik. Mivel pedig egyes levelezőprogramok (az Outlook különösen) a legújabb Received: fejlécet használják megjelenítési dátumként...

Íme a probléma. 15 000 email mutatja a migráció dátumát.

Tényleg "módosíthatók" ezek a dátumok?

Technikailag igen, az INTERNALDATE esetén (bizonyos megkötésekkel). Technikailag lehetséges, de felesleges a Date: esetén. A Received: fejléceknél pedig érdemes kicsit elidőzni.

Egy Received: fejléc átírása triviális. És azonnal kimutatható.

Egy Received: fejléc csupán egy szövegsor az üzenetben. Szerkeszthető, mint bármely szövegfájl. Pontosan olyan egyszerű, amilyennek látszik.

De íme, ami ezután következik.

Első probléma: a DKIM. A DKIM-aláírás (DomainKeys Identified Mail) az üzenet fejléceinek egy részhalmazán alapul, néha beleértve a Received: fejléceket is. Egy aláírt fejléc módosítása érvényteleníti az aláírást. Bármely fogadó szerver, amely DKIM-ellenőrzést végez, azonnal látja, hogy az üzenet módosult. Ez nem finom hamisítás, hanem egyenesen riasztó.

Második probléma: a belső azonosítók. A modern levelezési szerverek (Google Workspace, Microsoft 365) minden üzenethez egyedi, növekvő belső azonosítót rendelnek. Ezek az azonosítók összefüggnek az INTERNALDATE-tel és a beérkezési sorrenddel. Egy Received: módosítása, amely nincs összhangban ezekkel az azonosítókkal, olyan következetlenségeket okoz, amelyeket az auditnaplók azonnal észrevesznek.

Harmadik, praktikusabb probléma: még ha módosítja is a Received: fejlécet az üzenet tartalmában, az INTERNALDATE-et nem érintette, az még mindig az IMAP-feltöltés dátumát mutatja. A levelezőprogram továbbra is a helytelen dátumot jeleníti meg a rendezéshez. Az üzenetet hiába módosította.

Röviden: a Received: fejlécek átírása rosszindulatú céllal email dátumának meghamisítására technikailag triviális, egy szakértő másodpercek alatt kimutatja. Nem komoly irány.

A Date: fejléc: a múlt megváltoztatása papíron

Ugyanez a logika érvényes a Date: fejlécre is. Módosítható az üzenet törzsében. De a közbenső szerverek által hitelesített Received: fejlécek érintetlenek maradnak, és más történetet mesélnek el. Az időbeli láncolat következetlen. Bármely elemző vagy bíróság, amely összehasonlítja ezeket a mezőket, azonnal észreveszi.

Pontosabban fogalmazva: ez nem akadályozza meg, hogy egyes levelezőprogramok a módosított Date: fejlécet jelenítsék meg, ha közvetlenül egy .eml fájlt nyitnak meg. De egy éles levelezési szerver kontextusában, hitelesítéssel és naplókkal, a módosítás átlátszó.

Az IMAP-migráció: az egyetlen jogos kontextus a dátumjavításra

Egyetlen eset létezik, és csak egy, amelyben egy email fogadási dátumának módosítása nem csupán lehetséges, hanem technikailag indokolt: a rosszul kezelt IMAP-migráció által okozott károk javítása.

A konkrét helyzet a következő. Nemrég migrált 80 Exchange-postafiókot Microsoft 365-re. A migráció pénteken este fejeződött be. Hétfő reggel megérkeznek az első jegyek: "Minden emailem ugyanazt a dátumot mutatja", "Nem találom a tavalyi emailemet", "Az ügyfelem előzményei teljesen tönkrementek". 80 felhasználó akadt el, és a vezető választ vár.

Ebben a kontextusban a probléma dokumentált, azonosítható, és az oka egyértelmű: a migrációs eszköz egy Received: fejlécet adott hozzá a migráció napjának dátumával, és egyes levelezőprogramok ezt az új fejlécet használják megjelenítési dátumként. Az eredeti Date: fejléc viszont érintetlen minden üzenetben. Sohasem módosult. Még mindig az eredeti, helyes küldési dátumot tartalmazza.

A javítás tehát nem hamisítás: helyreállítás. Valódi adatokból indulunk ki (az eredeti Date: fejlécből) a konzisztens metaadatok rekonstruálásához. Ez alapvetően különbözik attól, mintha egy 2024-es emailt 2019-esnek próbálnánk beállítani.

Az egyes eszközökhöz tartozó konkrét mechanizmusokkal kapcsolatban ezek az útmutatók részletezik a valós eseteket: BitTitan migrációs dátumok javítása a Microsoft 365-ben, CloudM migrációs dátumok javítása az Outlookban, vagy imapsync migrációs dátumok javítása a Google Workspace-ben.

Miért kockázatos saját scriptet írni

Az alaplogika hozzáférhető. Bármely IT-rendszergazda, aki töltött időt IMAP-fórumokon, rekonstruálhatja az általános megközelítést. Ez nem a probléma.

A probléma az a szakadék, amely egy 50 teszt-emailen működő script és egy 40 000 üzeneten futó, egyetlen emailt sem elveszítő, egyetlen mellékletet sem megrongáló, egyetlen levelezési szálat sem megtörő éles script között tátong.

Néhány konkrét eset, amelyet a házilag készített scriptek általában nem kezelnek:

• S/MIME-mel aláírt emailek: az aláírás kiterjed a tartalomra és a fejlécekre is. Az üzenetstruktúra bármilyen módosítása érvényteleníti az aláírást. Egy ügyetlenül javított, aláírt email "érvénytelen aláírás" hibaüzenettel érkezik a címzettekhez.
• PGP-vel titkosított üzenetek: ugyanaz a problémakör, az implementációtól függően potenciálisan súlyosabb következményekkel.
• Nem ASCII-kódolású fejlécek: az RFC 2047 írja le a különleges karakterek fejlécbeli kódolását. Egy script, amely anélkül manipulálja a fejléceket, hogy kezelné ezeket az eseteket, csendesen megrongálja az ékezetes, japán karaktereket vagy arab neveket tartalmazó email tárgysorokat.
• API-rátakorlátok: a Google Workspace és a Microsoft 365 agresszív throttlingot alkalmaz. Hajnali 3-kor egy 10 000 emailes batch, amely exponenciális visszatartás nélküli kezeléssel találkozik 429 Too Many Requests hibával, félig javítva hagyja a postafiókokat.
• Sérült MIME-határok: a mellékleteket tartalmazó multipart üzeneteknek pontos MIME-határaik vannak. Helytelen újragenerálásuk olvashatatlanná teszi a mellékleteket.

És az a kérdés, amelyet egyetlen házilag készített script sem old meg: hogyan ellenőrizzük, hogy minden javított email sértetlen? Egy 40 000 üzenetet egyéni ellenőrzés nélkül módosító script egy fogadás. Fogadás olyan adatokra, amelyeket a felhasználók sok esetben pótolhatatlannak tartanak.

A migráció utáni dátumjavítás elérhető lehetőségeit részletező cikk bemutatja a különböző megközelítéseket, beleértve azok korlátait is.

Mit tesz a Redate.io ebben a kontextusban

A Redate.io kifejezetten erre az esetre lett tervezve: az IMAP-migráció által megrongált dátumok javítására, nagy léptékben, az üzenetek integritásának veszélyeztetése nélkül.

A szolgáltatás közvetlenül csatlakozik az érintett postafiókokhoz (Google Workspace-hez domain-delegáción keresztül, Microsoft 365-höz Azure AD-n át, vagy közvetlen IMAP-pal), ingyenesen átvizsgálja a hibás dátumú üzeneteket, majd egy saját fejlesztésű javítási folyamatot alkalmaz, amely kezeli a fent dokumentált határeseteket. Minden emailt egyedileg ellenőriz javítás után. Az eredetik egy 30 napig látható biztonsági mentési mappában maradnak.

A mintaillesztés több száz ismert migrációs eszköz aláírását fedi le: BitTitan MigrationWiz, CloudM, imapsync, GSMMO és ezek változatai. Az észlelés pontos: a Redate.io nem nyúl azokhoz az emailekhez, amelyeknek helyes a dátumuk.

Az árazási modell egyszerű: postafiókönkénti egyszeri fizetés, előfizetés nélkül. A diagnosztikai vizsgálat ingyenes, ami lehetővé teszi a károk mértékének felmérését bármilyen döntés meghozatala előtt.

Ha migráció után hibás dátumokat tapasztal az Outlookban, ez a cikk részletezi a leggyakoribb tüneteket és azt, hogyan lehet megkülönböztetni őket más okoktól.

Szeretné felmérni a probléma kiterjedését a postafiókjain? Indítson ingyenes vizsgálatot a Redate.io-n, és pontosan láthatja, hány email érintett, még bármilyen javítás előtt.