A három dátum minden email belsejében
Minden IMAP-szerveren tárolt email legalább három különálló dátumértéket hordoz. Ezeknek a dátumoknak a működése, és az, hogyan választják ki a levelezőkliensek, melyiket jelenítsék meg, a kulcs annak megértéséhez, miért rontja el a migráció a dátumokat. Ez a cikk az IMAP dátumrendszer mélyreható technikai elemzése, IT-adminisztrátorok és mindenki számára, aki meg szeretné érteni a migráció utáni dátumproblémák kiváltó okát.
1. Az RFC 2822 "Date" fejléc
A "Date" fejlécet az RFC 2822 (internetes üzenetformátum) definiálja. A feladó levelezőkliense állítja be az üzenet megírásának és küldésének pillanatában. Ez a fejléc magának az üzenettörzsnek a része, az üzenettel utazik és a kézbesítési úton lévő levelezőszerverek soha nem módosítják. Egy tipikus Date fejléc így néz ki:
Date: Mon, 15 Jan 2024 09:32:17 +0100
A Date fejléc az üzenet "küldési dátumát" jelöli. Ez a legmegbízhatóbb dátum, mert egyszer van beállítva és soha nem módosul. Ugyanakkor a feladó óráját tükrözi, amely lehet rosszul beállított. Ritka esetekben a Date fejléc teljesen hiányozhat (különösen automatikus rendszerértesítéseknél vagy rosszul formázott üzeneteknél).
2. Az IMAP INTERNALDATE
Az INTERNALDATE-et az RFC 3501 (IMAP4rev1 protokoll) definiálja. Ez egy szerver oldali metaadat-érték, amely a szerverhez való kézbesítés dátumát és időpontját jelöli. A Date fejléccel ellentétben az INTERNALDATE nem része magának az email-üzenetnek. Az IMAP-szerver külön tárolja metaadatként.
Amikor egy emailt normálisan kézbesítenek (nem migrálnak), az IMAP-szerver az INTERNALDATE-et az aktuális kézbesítési időpontra állítja. Ez az érték szorosan megegyezik a Date fejléccel, általában néhány másodperces vagy perces eltéréssel. A levelezőkliensek gyakran az INTERNALDATE-et használják "fogadási dátumként", mivel az tükrözi, mikor kapta ténylegesen a szerver az üzenetet.
És itt válik érdekessé a dolog. Amikor egy üzenetet az IMAP APPEND paranccsal illesztenek be (amit a migrációs eszközök használnak), az APPEND parancs lehetővé teszi a kliens számára az INTERNALDATE explicit megadását. A jól megtervezett migrációs eszközök használják ezt a funkciót a forrásszerver eredeti INTERNALDATE-jének megőrzéséhez. De még ha az INTERNALDATE helyesen van beállítva, az alább ismertetett "Received" fejléc probléma sok kliensben felülírhatja a megjelenített dátumot.
3. A "Received" fejlécek lánca
Minden alkalommal, amikor egy email áthalad egy levelezőszerveren, az a szerver egy "Received" fejlécet ad az üzenet elejéhez. Ez létrehoz egy Received fejléc-láncot, amely rögzíti az email útját a feladótól a címzettig. A legújabb (felül lévő) mutatja az utolsó szervert, amely feldolgozta az üzenetet, a legrégebbi (alul lévő) az elsőt.
Egy normál emailnek 3-6 Received fejléce lehet, amelyek dokumentálják az utat a feladó kimenő szerverétől a közvetítőkön át a címzett bejövő szerveréig. Minden Received fejléc tartalmaz egy időbélyeget. Egyszerűsített példa:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Hogyan választják ki a levelezőkliensek, melyik dátumot jelenítik meg
Outlook (Desktop, Web, Mobile)
A Microsoft Outlook az INTERNALDATE és a legújabb "Received" fejléc kombinációját használja a beérkezett üzenetekben megjelenített "Fogadva" dátum meghatározásához. A gyakorlatban az Outlook hajlamos a legújabb Received fejléc időbélyegét előnyben részesíteni a "Fogadva" oszlophoz. A "Küldve" oszlop a Date fejlécet használja. Mivel az Outlook alapértelmezetten a "Fogadva" oszlop szerint rendez, a Received fejléc időbélyege az, amit a felhasználók először látnak.
Apple Mail
Az Apple Mail macOS-en és iOS-en elsősorban az IMAP INTERNALDATE-et használja a dátum megjelenítéséhez. Ha az INTERNALDATE helyesen lett megőrizve a migráció során, az Apple Mail a helyes dátumot jelenítheti meg, de csak akkor, ha az INTERNALDATE kifejezetten be lett állítva az APPEND művelet során. Ha a migrációs eszköz nem állította be az INTERNALDATE-et, a szerver alapértelmezetten a beillesztési időt (a migrációs dátumot) használja. Az Apple Mail felhasználókra gyakorolt hatás részleteiért lásd: Apple Mail: rossz dátum migráció után.
Thunderbird
A Mozilla Thunderbird kínálja a legnagyobb rugalmasságot. Képes mind a "Dátum" (a Date fejlécből), mind a "Fogadva" (a Received fejlécekből) megjelenítésére. Alapértelmezetten a Thunderbird a Date fejléc értékét jeleníti meg, ami azt jelenti, hogy a dátumok helyesnek tűnhetnek a Thunderbirdben, még ha az Outlookban hibásak is. A Thunderbird "Fogadva" oszlopa mindig a migrációs dátumot mutatja. Bővebben lásd: Thunderbird: rossz dátum migráció után.
Gmail webes felülete
A Gmail webes kliens a Date fejlécet használja a dátum fő megjelenítéséhez. Ez azt jelenti, hogy a Gmail web gyakran helyes dátumokat mutat még migráció után is. De a Gmail szerveren az IMAP INTERNALDATE mégis hibás, ami érint minden IMAP-klienst, amely ehhez a Gmail-fiókhoz csatlakozik. A Gmail web és az Outlook vagy Apple Mail közötti különbség gyakori zavarforrás, és sok adminisztrátori hibakeresési időt emészt fel.
Miért rontja el az IMAP APPEND a dátumokat
Mi történik a migráció során
Amikor egy migrációs eszköz egy emailt az A szerverről a B szerverre helyez, az eszköz IMAP-on csatlakozik az A szerverhez és letölti a nyers üzenetet, majd csatlakozik a B szerverhez és az APPEND paranccsal beilleszti. A beillesztés során a B szerver feldolgozza a bejövő üzenetet és hozzáad egy új Received fejlécet az aktuális időbélyeggel: a migrációs dátummal. Ez a szabványos IMAP viselkedés, amelyet a protokoll definiál. A szerver minden APPEND-et új üzenetkézbesítésként kezel.
Az eredmény: szennyezett fejléc-lánc
Migráció után az email Received fejlécei így néznek ki:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
A migrációs eszköz Received fejléce most a legfelső bejegyzés. Minden levelezőkliens, amely a legújabb Received fejlécet használja a megjelenítési dátum meghatározásához (különösen az Outlook), "2025. április 11."-et fog mutatni "2024. január 15." helyett. Az eredeti Date fejléc és az eredeti Received fejlécek sértetlenül alatta vannak, de már nem abban a pozícióban, amelyet a levelezőkliensek előnyben részesítenek.
Még a jó INTERNALDATE kezelés sem akadályozza meg
Egyes migrációs eszközök helyesen állítják be az INTERNALDATE-et az APPEND során. Például az imapsync kifejezetten megőrzi a forrásszerver INTERNALDATE-jét. De a Received fejlécet a célszerver adja hozzá, nem a migrációs eszköz. A migrációs eszköznek nincs kontrollja e viselkedés felett. Még tökéletes INTERNALDATE megőrzéssel is a legfelső Received fejléc továbbra is tartalmazza a migrációs dátumot, és az olyan kliensek, mint az Outlook, továbbra is a rossz dátumot mutatják.
Tehát mit lehet konkrétan tenni?
Mely migrációs eszközök adnak hozzá Received fejléceket
Minden IMAP migrációs eszköz okozza ezt a problémát, mivel a Received fejlécet a célszerver adja hozzá, nem maga az eszköz. A hozzáadott fejléc tartalma az eszköztől és a szervertől függően változik.
A BitTitan MigrationWiz "mx.migrationwiz.com"-ot tartalmazó Received fejlécet ad hozzá. A CloudM Migrate "cloudm.io"-ra hivatkozó fejléceket ad hozzá. Az imapsync a célszerver általános Received fejlécét váltja ki. A GSMMO "gmailapi.google.com" hivatkozásokkal adja hozzá a fejléceket.
A javítás: helyes dátumok visszaállítása
A jó hír az, hogy a helyes dátuminformáció továbbra is létezik minden emailben. Az eredeti Date fejléc sértetlen. Az eredeti Received fejlécek sértetlenek. A probléma az, hogy egy szennyező fejléc ül fölöttük.
A Redate.io saját javítómotorja elemzi minden érintett email teljes fejléc-láncát, aláírás-illesztést alkalmazva ismert migrációs eszköz-aláírások százain, hogy pontosan azonosítsa, mely fejlécek igényelnek javítást. A többlépcsős elemzési folyamat kezeli azokat a szélső eseteket, amelyeknél az egyszerűbb megközelítések kudarcot vallanak: S/MIME aláírású üzenetek, PGP-titkosított tartalom, multipart/alternative struktúrák, Content-Transfer-Encoding problémák, nem ASCII fejlécek (RFC 2047), túlméretezett mellékletek és sérült MIME-határok.
Javítás után minden email integritásellenőrzésen megy át, amely megerősíti, hogy az üzenet szerkezete, tartalma és mellékletei azonosan megőrződtek. Az eredetik 30 napig látható biztonsági másolat mappában maradnak.
Lehetne szkriptet írni ennek megkísérlésére? Technikailag igen. De az "az emailek 95%-ánál működik" és az "az emailek 100%-ánál működik egyetlen sérülés nélkül" közötti különbség hónapok fejlesztését jelenti. És amikor valaki teljes postafiókjáról van szó, 5%-os hibaarány több száz csendben sérült üzenetet jelent anélkül, hogy ellenőrizni lehetne, mi romlott el.
Szeretné tudni, hány emailnek van hibás dátuma a postafiókjában? Indítson egy ingyenes elemzést a Redate.io-val, és kapjon azonnali kimutatást az érintett emailekről, fizetés nélkül.