Outlook profil újralétrehozása: miért változnak a dátumok?

A hibaelhárítási lépés, ami tönkreteszi a dátumokat

Egy felhasználó panaszkodik, hogy az Outlook nem szinkronizál. Az emailek nem érkeznek meg, az Elküldött mappában nem frissülnek az üzenetek, a töltőkerék csak forog. A technikus sérült profilt diagnosztizál, törli az OST-fájlt, majd teljesen újralétrehozza az Outlook-profilt. Eredmény: az Outlook újracsatlakozik, az emailek megjelennek, minden rendben látszik.

Aztán másnap reggel a felhasználó megnyitja a postafiókját, és rájön, hogy 8 évnyi levelezés ugyanazt a dátumot mutatja: a mai napot.

Ez pontosan ugyanaz a tünet, mint egy sikertelen IMAP-migrációnál. És ugyanolyan okokból.

Mi történik technikai szinten?

Ahhoz, hogy megértsük, miért okoz ez profil újralétrehozás ilyen eredményt, vissza kell térni egy különbséghez, amelyet a legtöbb technikus nem ismer jól: az email Date: fejlécének és az IMAP INTERNALDATE értékének különbségéhez.

Minden email tartalmaz az RFC 2822 fejléceiben egy Date: mezőt, amely jelzi, mikor küldték az üzenetet. Ezt a mezőt a feladó levelezőprogramja írja be küldéskor, majd az összes szerveren keresztül változatlanul eljut a postafiókunkba. Soha nem változik. Egy 2019. március 14-én 09:32-kor küldött email mindig megőrzi ezt a Date: fejlécet, bármilyen esemény következik be utána.

Az IMAP INTERNALDATE egészen más. Ez a levelezőszerver által kezelt metaadat, független az üzenet tartalmától. Azt jelzi, mikor "érkezett be" az üzenet a postafiókba. Normális körülmények között, amikor egy email SMTP-n érkezik, a szerver az átvétel időpontját rögzíti INTERNALDATE-ként. Egy 2019. március 14-én érkezett emailnek tehát az INTERNALDATE értéke összhangban van a küldési dátumával.

Az Outlook alapértelmezés szerint az IMAP-szerver által közvetített INTERNALDATE alapján rendezi és jeleníti meg az emaileket, nem az üzenet saját Date: fejléce alapján. (Ha valaha megnyitotta egy email teljes tulajdonságait Outlookban a nyers fejlécek megtekintéséhez, tudja, hogy ez nem épp olvasmányos szórakozás.)

Mit vált ki az OST-fájl törlése?

Amikor az Outlook IMAP-fiókot használ, helyi adatbázist tart fenn: az OST-fájlt (Offline Storage Table). Ez a fájl a szerveren tárolt emailek helyi tükröződése, azok metaadataival, olvasottsági állapotával, kategóriáival együtt.

Az OST-fájl törlése egyenlő ezzel a helyi tükörképpel való leszámolással. Az Outlooknak tehát mindent újra kell letöltenie az IMAP-szerverről.

A probléma? Amikor az Outlook IMAP-on keresztül letölt egy üzenetet, a FETCH paranccsal kéri le a tartalmat. De nem használja következetesen a FETCH INTERNALDATE parancsot az eredeti IMAP-dátum lekéréséhez és megőrzéséhez. Bizonyos Outlook-konfigurációkban és -verziókban a kliens a helyi indexet a letöltés időpontjával építi újra, nem a szerveren tárolt INTERNALDATE értékkel.

És ekkor a postafiók összes emailje az újratöltés napjának dátumát mutatja.

Nem minden Outlook-verzió viselkedik egyformán

Pontosítás: ez a viselkedés nem érinti az összes Outlook-verziót egyforma mértékben, és ez teszi a diagnosztizálást bonyolulttá.

Az Outlook 2016 és 2019 IMAP módban dokumentált helytelen indexújraépítési viselkedést mutat a gyorsítótár törlése után. Az új Outlook (webalapú, 2023 vége óta fokozatosan bevezetett) másképpen kezeli a gyorsítótárat, és változó eredményeket produkálhat. Az Exchange/Microsoft 365-ön keresztüli Outlook Exchange módban konfigurált fiókkal kevésbé érintett ebben a konkrét problémában, mert a MAPI/Exchange protokoll másképpen kezeli a szinkronizálást, mint az IMAP.

Ha azonban a felhasználó IMAP-fiókot használ klasszikus Outlookba konfigurálva, és egy technikus törölte az OST-fájlt vagy újralétrehozta a profilt: a kockázat valós.

Hogyan különíthető el a valódi migrációtól?

Egy IT-adminisztrátor, aki profilújralétrehozás után "hibás dátumok" ticketeket kap, tévesen migrációs problémára gondolhat. Íme, hogyan különböztethető meg a két eset.

IMAP-migráció esete

IMAP-migráció során (BitTitan, CloudM, imapsync stb.) a migrációs eszköz egyik szerverről a másikra másolja az emaileket. Minden másolt üzenethez a célszerveren egy új bejegyzést hoz létre az IMAP APPEND paranccsal. Ha az eszköz nem adja meg explicit módon az eredeti INTERNALDATE értékét ebben a parancsban, a célszerver az aktuális időpontot rögzíti INTERNALDATE-ként. Egyes eszközök ráadásul egy Received: fejlécet is hozzáadnak a migrációs dátummal, ami egyes klienseknél tovább rontja a helyzetet. Ennek a mechanizmusnak részleteit az IMAP INTERNALDATE és a hibás dátumok cikkünkben olvashatja.

Profilújralétrehozás esete

Ebben az esetben az emailek ugyanazon a szerveren vannak, az eredeti INTERNALDATE értékekkel. A szerver oldalán semmi sem változott. Kizárólag az Outlook helyi gyorsítótára épül újra helytelen dátumokkal. A látható tünet azonos (minden email ugyanazt a közeli dátumot mutatja), de az ok különböző.

Megerősítéshez: jelentkezzen be a postafiókba webmailen keresztül (Gmail, Outlook.com, vagy a tárhelyszolgáltató webmail-felülete). Ha a webmailen megjelenő dátumok helyesek, a probléma kizárólag az Outlook helyi gyorsítótárára vonatkozik. Ha a dátumok webmailen is hibásak, a probléma a szerver oldalán van (migráció vagy az INTERNALDATE értékek módosítása magán a szerveren).

Miért állíthatók vissza az eredeti dátumok?

Jó hír: mindkét esetben (migráció vagy profilújralétrehozás) az eredeti dátumok nem vesznek el.

Az RFC 2822 Date: fejléc az üzenet szerves része. Ugyanolyan megváltoztathatatlan, mint az üzenet szövegtörzse vagy a csatolmányok. Egy 2017-ben küldött email nyers szövegében valami ilyesmi szerepel:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Ez a sor jelen van a szerveren tárolt üzenetben. Nem módosult. Amit az Outlook (helytelenül) megjelenít, az az üzenet tartalmán kívüli metaadat.

Ez teszi lehetővé a javítást. A Redate.io motorja minden üzenet fejlécláncolatát elemzi, hogy kinyerje a valódi eredeti dátumot, majd célzott metaadat-korrekciót végez az üzenet tartalmának módosítása nélkül. Az Outlook által látott INTERNALDATE az üzenetben mindig jelen lévő hiteles információból rekonstruálódik.

A "tiszta" újralétrehozás csapdája

Megoldotta az egyik felhasználó szinkronizálási problémáját. Az Outlookja ismét működik, az új emailek megérkeznek. Lezárja a ticketet.

Három nappal később a felhasználó visszahív: egy tavalyi szállítói emailt keres, de az Outlookban az összes 2023-as levele úgy jelenik meg, mint amit "tegnap" kapott. Semmit sem talál. Az automatikus archiválás esetleg friss emaileket kezelt régiként. A főnöke pedig egy 2022. szeptemberi emailbeszélgetést kér egy jogi ügy kapcsán.

Ez a forgatókönyv rendszeresen előfordul. Nem azért, mert a technikus rosszul végezte a munkáját, hanem mert ez az Outlook-viselkedés nincs láthatóan dokumentálva a szokásos hibaelhárítási útmutatókban.

A hamis megoldások, amelyek nem segítenek

Az emailek rendezése "Küldési dátum" szerint a "Fogadási dátum" helyett az Outlookban az első dolog, amit a felhasználók kipróbálnak. Ez működni is látszik... amíg rá nem jönnek, hogy a küldési dátum szerinti rendezés csak bizonyos mappákban érhető el, eltűnik nézet váltásakor, és más alkalmazások (mobilon, webmailen, automatikus rendezési szabályokban) továbbra is a helytelen INTERNALDATE értéket használják.

A küldési dátum szerinti rendezés nem megoldás. Ez egy ragtapasz, amely elfedi a tünetet, de nem érinti a valódi problémát. Erről részletesen írtunk a Rendezés küldési dátum szerint nem megoldás cikkünkben.

Másodszor is újralétrehozni a profilt? Ez semmit sem változtat, ha az Outlook viselkedése amúgy is az aktuális dátummal építi újra a gyorsítótárat.

Exportálás majd PST-be visszaimportálás? Vigyázat. A hibás dátumokkal rendelkező Outlookból végzett PST-export a sérült metaadatokat is exportálja. A PST-fájl tartalmazni fogja a rossz dátumokat. Ennek visszaimportálása nem javít semmit, sőt rosszabbá teheti a helyzetet, inkonzisztens dátumokkal rendelkező duplikátumokat létrehozva. Erről külön cikkben írunk: PST-import Outlookban: miért lesz minden email mai dátumú?

Mit tesz a Redate.io ebben a konkrét esetben?

Akár IMAP-migrációból, akár Outlook-profilújralétrehozásból ered a probléma, a szerver oldalán az eredmény hasonló: olyan emailek, amelyek dátum-metaadatai inkonzisztensek a valódi tartalmukkal.

A Redate.io közvetlenül csatlakozik a postafiókhoz (Google Workspace, Microsoft 365 vagy közvetlen IMAP), végigvizsgálja az összes üzenetet a helytelen metaadatok azonosításához, majd többlépéses elemzési folyamatával minden egyes emailt egyenként javít. Minden javítást ellenőriz. Az eredeti üzeneteket egy látható biztonsági mentési mappában megőrzi, amíg a felhasználó maga nem törli azokat.

A folyamat kezeli azokat a határeseteket, amelyeket a házi készítésű szkriptek rendszeresen elbuknak: S/MIME-aláírással ellátott üzenetek, nem ASCII-kódolású fejlécek (RFC 2047), összetett multipart-struktúrák, nem szabványos vagy hibás időzónával rendelkező Date: fejlécek. Egy szkript, amely 50 teszt-emailen helyesen fut egy fejlesztői postafiókban, visszafordíthatatlanul 2000 üzenetet rongálhat meg éles környezetben. Nincs natív visszagörgetési lehetőség IMAP-on, ha egy üzenetet előzetes biztonsági mentés nélkül helyettesítünk.

Az Outlookhoz kapcsolódó esetekhez a kézi IMAP másolás dátumok javítása az Outlook-ban javítási oldal részletezi a postafiók csatlakoztatásának és az elemzés elindításának lépéseit.

A probléma megelőzése a következő beavatkozásoknál

Ha Ön technikus vagy IT-adminisztrátor, és rendszeresen végez beavatkozást Outlook-profilokon, néhány szokás segíthet elkerülni ezt a helyzetet.

Mielőtt törölne egy OST-fájlt vagy újralétrehozna egy profilt, ellenőrizze a webmailen megjelenő dátumokat. Ha helyesek, jegyezze fel a ticketben. Az újralétrehozás után jelentkezzen be újra webmailen, és hasonlítsa össze az ott megjelenő dátumokat az Outlookban láthatókkal. Ha eltérés mutatkozik, a probléma azonnal azonosítható, még mielőtt a felhasználó három nap múlva panaszkodna.

Tervezett migrációkhoz az email migráció ellenőrzőlista felsorolja az előtte és utána elvégzendő ellenőrzéseket, hogy az ilyen típusú problémák az művelet végén azonnal észlelhetők legyenek.

Újralétrehozta az Outlook-profilját, és a postafiókjában most minden dátum hibás? Indítson el egy ingyenes vizsgálatot a Redate.io-n, és azonosítsa az érintett emaileket, majd javítsa a metaadatokat az üzenetek tartalmának módosítása nélkül.