PST-import Outlookban: miért lesz minden email mai dátumú?

A tünet: minden emailen a mai dátum szerepel

Végzett a PST-import az Outlookban. A folyamatjelző elérte a 100%-ot, minden simán ment. Aztán megnyitja a beérkező üzeneteket... és minden importált emailen a mai dátum szerepel. Egy 2019-es üzenet, egy 2021-es, egy öt éve archivált levél: mind ugyanazt a dátumot mutatja. Az import napját.

Ez nem megjelenítési hiba. Nem időzóna-probléma. Tökéletesen dokumentált viselkedés, amely összefügg azzal, ahogy az IMAP kezeli a dátum-metaadatokat. Mégis katasztrofális mindazok számára, akiknek régi emailjeiket dátum szerint kell megtalálniuk.

A helyi PST és az IMAP: két teljesen különböző világ

Mielőtt megmagyaráznánk, miért romlanak el a dátumok, érdemes megérteni, mi is egy PST-fájl a dátumkezelés szempontjából.

A PST (Personal Storage Table) egy Microsoft-tulajdonú formátum. Az emaileket teljes metaadataikkal együtt tárolja: küldési dátum, fogadási dátum, mellékletek, kategóriák, olvasottsági jelzők. Ezeket a metaadatokat az Outlook közvetlenül kezeli, minden levelezési protokolltól függetlenül. Ha egy PST-fájlt kiszolgálóhoz való csatlakozás nélkül nyit meg az Outlookban, a megjelenített dátumok közvetlenül a PST-fájl belső mezőiből származnak. Eddig minden rendben.

A probléma akkor jelenik meg, amikor ezt a tartalmat IMAP-kiszolgálón tárolt postafiókba próbálja átvinni, legyen az Microsoft 365, Google Workspace vagy bármilyen hagyományos tárhelyszolgáltató. Ekkor elhagyja a PST-világot, és belép az IMAP-világba, ahol teljesen más szabályok érvényesek.

Az IMAP APPEND és az INTERNALDATE: a probléma gyökere

Az IMAP-ban a szerveren tárolt minden üzenethez kétféle dátumérték tartozik:

• A Date: fejléc (RFC 2822), amely magának az üzenetnek a tartalmához tartozik. Ez a küldő által az üzenetbe írt dátum.
• Az INTERNALDATE, amelyet az IMAP-szerver kezel. Ez azt a pillanatot jelzi, amikor az üzenetet a szerverre helyezték. Az Outlook ezt az értéket használja az üzenetek rendezésekor a "Fogadás dátuma" nézetben.

(Ha valaha is megpróbált nyers email-fejléceket olvasni, tudja, hogy az nem éppen strandolvasás. De ott zajlik minden.)

Amikor egy email normálisan érkezik a szerverére, a levelezőszerver automatikusan beállítja az INTERNALDATE értékét a fogadás pontos pillanatára. Az Outlookban megjelenített dátum tehát valóban azt mutatja, mikor kapta az üzenetet.

Amikor az Outlook PST-fájlt importál egy IMAP-postafiókba, az IMAP APPEND paranccsal küldi a szervernek az egyes üzeneteket. Az IMAP-szabvány lehetővé teszi explicit INTERNALDATE megadását az APPEND műveletnél. Az Outlook azonban ezt nem teszi meg. Megadott INTERNALDATE nélkül küldi az üzeneteket. A szerver ilyenkor az alapértelmezett szabályt alkalmazza: az INTERNALDATE értékét az aktuális időre állítja, vagyis az import pillanatára.

Eredmény: 8000 importált email, 8000 emailen a mai dátum.

Miért viselkedik így az Outlook?

Ez nem Microsoft-hiba. Implementációs döntés, amely annak idején valószínűleg ésszerűnek tűnt: a PST-import eredeti felhasználási esetében a felhasználó helyben archiválja az üzeneteket, majd "importálja" őket az aktuális postafiókjába. A rendezéshez releváns dátum az eredeti fogadási dátum lenne... de a Microsoft úgy döntött, nem propagálja az INTERNALDATE értékét az import művelet során.

Pontosabban fogalmazva: ez a viselkedés az Outlook beépített importálójára vonatkozik (Fájl > Megnyitás és exportálás > Importálás/exportálás). Más importálási módszerek, például bizonyos külső eszközök vagy az Exchange felügyeleti központon keresztüli migrációk, az IMAP APPEND implementációjuktól függően eltérően viselkedhetnek.

Ez a viselkedés évek óta ismert és dokumentált a Microsoft fórumokon. Nem változott sem az Outlook 2016-tal, sem a 2019-essel, sem a jelenlegi Microsoft 365-ös verziókkal. Aki ma importál PST-fájlt, pontosan ugyanazzal a problémával találkozik, mint 2015-ben.

Miben tér el ez a hagyományos IMAP-migrációtól?

Ez az érdekes rész, mert a PST-import hasonló végeredményt produkál, mint egy hagyományos IMAP-migráció hibás dátumokkal, csak más mechanizmus révén.

Egy tipikus IMAP-migráció során, például a BitTitan MigrationWiz vagy az imapsync segítségével, az emailek forrás-IMAP-kiszolgálóról kerülnek a cél-IMAP-kiszolgálóra. A migrációs eszköz lekéri az üzeneteket, majd visszaszúrja őket az IMAP APPEND paranccsal. Egyes eszközök helyesen megőrzik az INTERNALDATE értékét, mások nem. Minden esetben az üzenetekhez hozzáadódik egy Received: fejléc a migráció dátumával, amely az INTERNALDATE-től függetlenül is megzavarhatja az Outlookban megjelenő dátumot.

PST-import esetén a mechanizmus egyszerűbb: nem adódik hozzá migrációs Received: fejléc (a PST-fájlok nem haladnak át közbenső levelezőkiszolgálón), de az INTERNALDATE egyszerűen soha nem kap helyes értéket. A látható eredmény ugyanaz, az ok kissé eltér.

Ez a különbség közvetlen következménnyel jár a javítás szempontjából: az IMAP-migrációhoz és a PST-importhoz nem egészen ugyanazt a megközelítést kell alkalmazni. Lásd még: miért okoz hibás dátumokat az IMAP INTERNALDATE - részletes magyarázat mindkét esetről.

Miért nem segítenek az Outlook nézeti beállításai?

A szokásos első reakció a probléma felismerésekor az Outlook beállításainak átvizsgálása. Van is egy ígéretesnek tűnő lehetőség: az emailek rendezése "Dátum" szerint, "Fogadás dátuma" helyett.

A küldési dátum szerinti rendezés nem megoldás. Ragtapasz.

Íme, miért: még ha átállítja is a rendezést a "Dátum" oszlopra (amely az üzenet Date: fejlécének felel meg, tehát az eredeti dátumnak), több probléma is megmarad:

• Az Outlook keresője az INTERNALDATE alapján indexel. A "2020 januári emailek" keresés nem fogja megtalálni az importált 2020 januári üzeneteket, mert az INTERNALDATE szerint az import napján érkeztek.
• Az Outlook felületén a "Ma", "Ez a hét", "Ez a hónap" mappák az INTERNALDATE alapján működnek, nem a Date: fejléc alapján.
• A webes felületeken (Outlook Web App, Gmail) és mobil klienseken a megjelenített dátum és a rendezési viselkedés szinte mindig a szerveri INTERNALDATE-től függ.
• A fogadási dátumra alkalmazott automatikus szabályok és szűrők nem fognak helyesen működni.

A nézet megváltoztatása egy adott felhasználó számára, egy adott kliensprogramon, egy adott konfigurációban megoldja a megjelenítést. A forrást nem javítja ki.

Az OST újraszinkronizálása sem segít

Másik klasszikus kísérlet: az OST-gyorsítótár törlése és a teljes újraszinkronizálás kényszerítése a szerverről. Az ötlet mögötti logika: talán a probléma az Outlook helyi gyorsítótárából ered, nem a szerverről.

Zsákutca. Az OST-fájl egy helyi gyorsítótár, amely az IMAP-szerver állapotát tükrözi. Ha az INTERNALDATE hibás a szerveren, az OST is hibásat fog mutatni újraszinkronizálás után. Az OST törlése semmit sem változtat az Exchange Online-on vagy a Google Workspace-en tárolt adatokon. A szerver az irányadó.

A dátumokat csak úgy lehet javítani, ha a metaadatokat közvetlenül a szerveren korrigálja, üzenetről üzenetre. És pontosan itt válik bonyolulttá a kézi beavatkozás.

Az arányok problémája: 1 email triviális. 15 000 már más lapra tartozik

Technikailag, ha valaki megérti a problémát, elképzelheti, hogy ír egy scriptet, amely végigmegy a postafiókban, beolvassa minden üzenet Date: fejlécét, és ennek megfelelően javítja az INTERNALDATE értékét. Megérteni a problémát az egyik dolog. Javítani 15 000 emailen egyetlen elveszett üzenet nélkül az egészen más.

Néhány valós körülmény:

• A Microsoft Graph és a Gmail API rate limiteket (kérésszám-korlátokat) alkalmaz. Egy egyszerű script 429 Too Many Requests hibákat fog kapni, egy javítás közepén megszakad, és a postafiókot részben javítva hagyja, anélkül hogy tudnánk, mely üzenetek kerültek feldolgozásra és melyek nem.
• Egyes PST-fájlban lévő emailek Date: fejléce hibás vagy hiányzik. Egy script, amely nem kezeli ezeket a szélső eseteket, megrongálhatja vagy csendben kihagyhatja ezeket az üzeneteket.
• Az aláírt (S/MIME) vagy titkosított (PGP) emailekre kiegészítő integritási követelmények vonatkoznak. A metaadataik óvatlan módosítása érvénytelenítheti a kriptográfiai aláírást.
• A komplex MIME-határokkal rendelkező multipart/alternative struktúrák néha kiszámíthatatlanul reagálnak a módosítási műveletekre.
• Nincs visszaállítási mechanizmus. Ha valami félremegy a feldolgozás közepén, hogyan lehet visszatérni a kezdeti állapothoz?

Egy script, amely 10 tesztemailen működik, nem fog működni egy 50 000 üzenetes éles postafiókban. Tavaly egy ügyfélnek volt egy 40 GB-os PST-archívuma, amelyet egy Stack Overflow-ról letöltött Python-scripttel próbált megjavítani. Eredmény: 3000 duplikált email, 200 üzenet elérhetetlen mellékletekkel, és két hét kézi tisztogatás.

Mit csinál ebben az esetben a Redate.io?

A Redate.io elemzi a cél-postafiókban lévő minden üzenet metaadatait, azonosítja a hibás dátumú emaileket (beleértve a PST-importból származókat is), és saját fejlesztésű motorjával elvégzi a javítást. A többlépéses elemzési pipeline összehasonlítja minden üzenet fejlécláncolatát, RFC-megfelelőségi ellenőrzéssel kinyeri az eredeti dátumot, majd célt metaadat-korrekciót hajt végre az üzenet tartalmának módosítása nélkül.

Minden javított emailt egyenként ellenőriz. Az eredetik egy jól látható biztonsági mentési mappában maradnak 30 napig, mielőtt bármilyen végleges módosítás megtörténne. A javítás a három fő platformon működik: Microsoft 365-ön (Azure AD-n keresztül), Google Workspace-en (tartomány-delegáción keresztül), és hagyományos tárhely-szolgáltatók esetén közvetlen IMAP-on.

A kezdeti scan ingyenes. Megmutatja pontosan, hány email érintett és milyen a hibás dátumok eloszlása, mielőtt bármilyen döntést kellene hozni.

Lásd még:

• Email dátumok javítása Microsoft 365 migráció után
• Outlook: IMAP migrációs dátum vs. elküldési dátum
• Javíthatók-e az email dátumok migráció után?

A PST-import felülírta az összes email dátumát? Szkennelje be ingyenesen postafiókját a Redate.io-n, és mérje fel a probléma mértékét, mielőtt lépéseket tenne.