Minden régi emailem ugyanazt a dátumot mutatja - miért?

A tünet: régi emailek egyetlen dátumra torlódva

Reggel megnyitja az Outlookot, a Gmailt vagy az Apple Mailt. Valami nem stimmel. Több száz, néha több ezer régi email egyazon dátumot mutat: néhány nappal vagy néhány héttel ezelőttit. 2021-es, 2019-es, 2016-os üzenetek úgy jelennek meg, mintha tegnap érkeztek volna. A dátum szerinti rendezés értelmetlenné válik. Keres egy fontos emailt a tavalyi évből, de az ezer üzenet között kallódik, amelyek mind ugyanazon a napon látszanak beérkezni.

Az új emailek viszont helyes dátumokat mutatnak. Kizárólag a régi üzenetek érintettek.

Mi a csuda történhetett?

Az első reakció: a szoftvert hibáztatjuk

Az ember természetesen hibára gyanakszik. Összeomlott az Outlook. Félresikerült frissítés. Sérült fájl. És ekkor kezdődik a kálvária: megkeresi, hogy "Outlook dátum hiba", belefut fórumokba, amelyek OST fájlokról, SCANPST.exe-ről, az Outlook-profil nulláról való újralétrehozásáról értekeznek...

Eltölt két órát az újrapróbálkozásokkal. A probléma megmarad.

Egyébként a SCANPST egy helyi Outlook adatfájlokat javító eszköz. Bizonyos fájlsérüléseket ki tud javítani, de a levelezőszerveren tárolt adatokhoz nem nyúl. Vagyis még ha tökéletesen meg is javítja az OST fájlját, a dátumok továbbra is hibásak lesznek, mert a probléma nem az Ön gépén van.

A probléma magukban az emailekben van, a szerveren.

Ami valójában történt: egy migráció

Az esetek túlnyomó többségében ez a tünet email-migráció után jelenik meg. A cég átváltott egy régi rendszerről Google Workspace-re, Microsoft 365-re, vagy egy új szerverre. Valaki, valahol, egy eszközt használt az összes email átvitelére az egyik helyről a másikra.

Lehet, hogy nem tájékoztatták erről. Vagy tudott róla, de nem hozta összefüggésbe a dátumproblémával. Ez teljesen normális.

Ezek a migrációs eszközök hatalmas munkát végeznek: ezreket, tízezereket másolnak, teljes mappákat, mellékleteket. De van egy elég alattomos mellékhatásuk. Amikor egy emailt egyik szerverről a másikra visznek át, az eszköz egy apró technikai sort illeszt az üzenetbe, az úgynevezett "Received:" fejlécet, amely jelzi, mikor érkezett az üzenet az új szerverre. Vagyis: a migráció dátumát.

Ez a probléma gyökere.

Hogyan dönti el a levelezőprogram, melyik dátumot mutassa?

Egy email valójában több különböző dátumot tartalmaz, a technikai adataiba rejtve. Van az eredeti küldési dátum (amelyet általában lát), de vannak "Received:" fejlécek is, amelyek az üzenet internetes útjának minden állomását rögzítik.

(Ha valaha rákattintott a "Forrás megjelenítése" vagy "Teljes fejlécek megtekintése" opcióra egy emailben, lehet, hogy látta ezeket a rejtélyes sorokat, amelyek érthetetlen szövegtömbre hasonlítanak. Pontosan erről van szó.)

Normál esetben a levelezőprogram a legújabb "Received:" fejlécet nézi meg, hogy meghatározza az email megjelenítési dátumát. Ez a logika tökéletesen működik: az utolsó "Received:" mindig megfelel az üzenet postaládába érkezésének, vagyis küldés után néhány másodperccel.

De migráció után ez a logika visszaüt. A migrációs eszköz egy új "Received:" fejlécet szúrt be legfelülre, az átvitel dátumával. A levelezőprogram ezt a fejlécet olvassa először, látja a migrációs dátumot, és azt jeleníti meg. Az eredeti küldési dátum ott van, sértetlenül, mélyebben elásva az email adataiban. De a program nem látja, mert megáll az első fejlécnél.

Eredmény: 8000 email, amelyek mind ugyanarról a novemberi keddi napról látszanak beérkezni.

Melyik eszközök okozzák ezt a problémát?

A legelterjedtebb migrációs eszközök mindegyike mutatja ezt a viselkedést. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (a Google ingyenes eszköze Outlookból való migráláshoz) és még sokan mások. Nem igazán az ő hibájuk: az email protokoll technikai működésének következménye. Ezek az eszközök azért adják hozzá ezt a fejlécet, mert ezt írja elő a protokoll, amikor egy üzenetet egyik szerverről a másikra továbbítanak.

A gond az, hogy senki nem figyelmezteti a felhasználókat, hogy ez meg fog történni.

Ha a cég nemrég váltott levelezőrendszert, vagy az IT-részleg elvégzett egy "felhőbe való migrációt", valószínűleg ez a probléma forrása. Ellenőrizheti az érintett dátumokat: mindegyik nagyjából ugyanarra az időszakra esik? Ha igen, ez az időszak a migráció ideje.

A zsákutcák, amelyeket érdemes elkerülni

Néhány megoldás, amelyek fórumokon rendre felmerülnek, de nem működnek:

Adatfájl javítása SCANPST-vel

Fentebb már érintettük: a SCANPST a helyi Outlook fájlokat javítja (a számítógépen tárolt .pst vagy .ost fájlokat). A szerveren lévő emaileket nem módosítja. Javítás után az emailek ugyanolyan rossz dátumokat fognak mutatni, mert ezek a dátumok magukban az emailekben vannak, nem a helyi fájlban.

Az Outlook-profil újralétrehozása

Ugyanaz a logika. Az Outlook-profil újralétrehozása azt jelenti, hogy helyben tiszta lappal indulunk, majd az összes emailt újra letöltjük a szerverről. Az újra letöltött emailek pontosan ugyanolyan hibás dátumokkal rendelkeznek majd, mint korábban. Csak elveszítette az időt a teljes újrakonfigurálással.

Rendezés "küldési dátum" szerint a "beérkezési dátum" helyett

Egyes fórumok azt javasolják, hogy változtassa meg a rendezési szempontot az Outlookban, váltson beérkezési dátumról küldési dátumra. Ez bizonyos esetekben segíthet... de nem mindig. Más szoftverek, más eszközök vagy más személyek esetén, akik hozzáférnek a postaládájához, semmit nem old meg. A mélyen fekvő ok ott marad. A küldési dátum szerinti rendezés nem megoldás, csak tapasz.

A levelezőprogram újratelepítése

Nem. Az emailek a szerveren vannak, nem a szoftverben. Az Outlook, a Gmail, az Apple Mail vagy a Thunderbird újratelepítése semmit nem változtat az online tárolt adatokon.

A jó hír: az eredeti dátumok még ott vannak

Van egy fontos dolog, amelyet érdemes megérteni, és amely lehetővé teszi a javítást: minden email eredeti küldési dátuma nem törlődött. Ott van még az emailben, egy "Date:" nevű fejlécben, amely az elküldő által beállított küldési dátumot tartalmazza. Ez egy email-szabvány (amelyet egy RFC 2822 nevű technikai specifikáció határoz meg), amelyet minden migrációs eszköz betart, mert a módosítása súlyos szabványsértés lenne.

Más szóval, ha 2022. március 14-én kapott egy emailt, az email még mindig tartalmazza ezt a dátumot valahol az adataiban. Csupán már nem azt jeleníti meg elsőként a levelezőprogram.

Pontosan ez teszi lehetővé a javítást. A probléma nem adatvesztés. Ez a metaadatok olvasásának kérdése: a levelezőprogram a rossz dátumot olvassa, miközben a helyes dátum még mindig jelen van.

Miért kockázatos saját kezűleg megpróbálni javítani?

Felmerülhet a kérdés, hogy egy informatikus egyszerűen írhat-e egy scriptet a probléma megoldásához. Megérteni, mi történik, az egy dolog. Helyesen javítani ezreket emailen anélkül, hogy egyet is elveszítene, az egészen más.

Egy email nem egyszerű szöveges fájl. Tartalmazhat mellékleteket, digitális aláírásokat, összetett formátumban kódolt tartalmakat. Az ilyen üzenetek metaadatainak módosítása anélkül, hogy szétesne, tucatnyi különleges esetet igényel: elektronikusan aláírt üzenetek (S/MIME), titkosított emailek (PGP), nem szabványos kódolások, többrészes struktúrák... Egy házi script, amely 20 testemailnél működik, nagy valószínűséggel nem fog helyesen működni egy 15 000 üzenetes éles postaládánál. És ha valami elromlik, hogyan lehet megbizonyosodni arról, hogy egyetlen email sem sérült vagy veszett el? Házi scripttel: lehetetlen.

Egyedi mentési és ellenőrzési mechanizmus nélkül minden egyes emailhez a járulékos károk kockázata nagyon is valós.

Mit csinál a Redate.io?

A Redate.io egy kifejezetten erre a problémára tervezett szolgáltatás. Csatlakozik a postaládájához (Google Workspace, Microsoft 365 vagy egy IMAP-szerver), azonosítja azokat az emaileket, amelyeknek a dátumát migráció rontotta el, és egy saját fejlesztésű korrekciós motor segítségével javítja őket, amely elemzi a fejlécek teljes láncát és minden egyes üzenet dátum-metaadatait rekonstruálja.

Minden javított emailt egyedileg ellenőriz. Az eredetik egy 30 napig látható mentési mappában megmaradnak. Ha valami nem stimmel, vissza lehet lépni.

A kezdeti scan ingyenes: a Redate.io elemzi a postaládáját, és pontosan megmutatja, hány email érintett, mielőtt bármit eldöntene. Semmi meglepetés.

Az árazás egyszeri fizetés, a javítandó emailek mennyiségén alapul. Nincs előfizetés. Egyszer fizet, a probléma megoldódik.

Látni szeretné a károk mértékét, mielőtt elköteleződne? Indítson el egy ingyenes postaláda-scant a Redate.io oldalon, és néhány perc alatt kiderül, hány email érintett.