Új Outlook: hibás dátumok migráció után - valódi okok

Két Outlook, két viselkedés - ugyanazokkal az emailekkel

Ha nemrég migráltál postafiókokat Microsoft 365-be, és egyes felhasználók azt panaszolják, hogy minden régi emailjük ugyanazt a dátumot mutatja (a migráció napját), akkor lehet, hogy észrevettél valami furcsát: a klasszikus Outlookot használók néha a helyes dátumot látják az olvasóablakban, míg az új Windows-os Outlookon lévők következetesen a migrációs dátumot. Ugyanaz a postafiók. Ugyanazok az emailek. Mégis különböző eredmény.

Ez nem bug a szó klasszikus értelmében. Ez egy architekturális döntés, amelynek közvetlen következményei vannak arra, hogyan jelennek meg a dátumok IMAP-migráció után. A megértéséhez bele kell menni az email fejlécek és az IMAP protokoll részleteibe - ami igazából nem könnyű olvasmány, de megmagyarázza, miért nem elegendő semmiféle kliensoldali beavatkozás a probléma megoldásához.

Az IMAP INTERNALDATE: a valódi bűnös

Amikor egy emailt IMAP-szerveren tárolnak, két különböző dátuma létezik egymás mellett, amelyek nem azonosak egymással.

Az első a Date: fejléc, amelyet az RFC 2822 szabványoz. Ez az üzenetbe beírt dátum - az, amelyet a feladó az email küldésekor rögzített. Az üzenet testének része, és soha nem változik, függetlenül attól, milyen úton jut el az email a céljához.

A második az INTERNALDATE, egy szerver által kezelt IMAP-metaadat, amely az üzeneten kívül létezik. Ez az a dátum, amelyen a szerver rögzítette az üzenetet. Normál migráció esetén a megbízható eszközök megőrzik az eredeti INTERNALDATE-et. Rosszul konfigurált migráció esetén azonban, vagy olyan eszközökkel, amelyek ezt a metaadatot nem kezelik megfelelően, az INTERNALDATE visszaáll a migráció napjának dátumára. Az eredmény: minden migrált email ugyanazt a fogadási dátumot viseli a szerver szempontjából.

(Egyébként, ha valaha is olvastál imapsync vagy MigrationWiz naplókat, tudod, hogy léteznek speciális beállítások az INTERNALDATE megőrzésének megkísérlésére. Ezek a beállítások nem mindig működnek, és egyes célszerverek egyszerűen figyelmen kívül hagyják őket.)

A klasszikus Outlook: hogyan olvassa a dátumokat

A klasszikus Outlook, vagyis a helyileg telepített COM-alapú verziók (Outlook 2016, 2019, 2021 és a Microsoft 365 Apps asztali kliens), valamivel összetettebb mechanizmust használ annak meghatározásához, hogy melyik dátumot jelenítse meg az üzenetlistában.

Az Elküldött elemek mappában az Date: fejlécre támaszkodik. A beérkezett emaileknél elsődlegesen a szerver INTERNALDATE-jét használja, de bizonyos körülmények között (különösen amikor az OST gyorsítótár érintett, vagy az olvasóablakban való első megjelenítéskor) a Received: fejlécek láncát is elolvashatja, hogy hozzávetőleges eredeti dátumot rekonstruáljon.

Ezért figyelhető meg ez az ellentmondásos viselkedés: a klasszikus Outlook néha a helyes dátumot mutatja az olvasóablakban, mert a részletes előnézethez az üzenet eredeti Date: fejlécét olvassa, még ha az emailek listája maga a sérült INTERNALDATE-et használja is. De figyelem, ez nem megbízható, és semmit sem javít. A rendezés továbbra is hibás marad, a dátum szerinti keresések továbbra is helytelen eredményt adnak.

Az új Outlook: gyökeresen eltérő architektúra

Az új Windows-os Outlook, amelyet 2023 végétől fokozatosan vezettek be, már nem COM-alapú alkalmazás. Lényegében egy Progressive Web App (PWA), amely ugyanazon kódbázison alapul, mint az Outlook on the web (OWA). Ennek az újratervezésnek mélyreható következményei vannak.

Az új Outlook a dátumok megjelenítését teljesen a Microsoft 365 API-ra bízza. Nem olvassa a Received: fejléceket, nem ás bele a fejlécláncba, hogy megtalálja az eredeti dátumot, és semmiféle kliensoldali rekonstrukciót nem kísérel meg. Egyszerűen azt jeleníti meg, amit a szerver visszaad: az INTERNALDATE-et.

Az eredmény: ha az INTERNALDATE sérült a migráció során, az új Outlook egy pillanatig sem habozik. A migrációs dátumot jeleníti meg minden érintett emailnél, kivétel és árnyalat nélkül. Ez konzisztensebb és kiszámíthatóbb viselkedés, mint a klasszikus Outlooké, de azonnal láthatóvá és figyelmen kívül hagyhatatlanná teszi a migrációs problémát.

Egy admin, aki 300 postafiókot migrál péntek este, hétfő reggel fogja felfedezni, hogy az új Outlookot használó összes felhasználó teljes archívuma a múlt hétvégi dátumot mutatja. A ticketek gyorsan érkeznek.

Miért nem működik egyetlen kliensoldali megoldás sem

Sok admin kliensoldali megoldásokat próbál ki, mielőtt megértené, hogy a probléma a szerveren lévő adatokban van. Íme a klasszikus kísérletek, és miért vallanak kudarcot.

Rendezés "Küldési dátum" szerint a fogadási dátum helyett

A küldési dátum szerinti rendezés Outlookban az üzenet Date: fejlécére támaszkodik, amely maga érintetlen. Tehát igen, ez a rendezés működhet. De ez csak ragtapasz, nem megoldás. A dátum szerinti keresések továbbra is hibásak maradnak. A dátum alapú szabályok továbbra is használhatatlanok. És ami a legfontosabb: a felhasználónak minden mappát, minden postafiókot kézzel kell újrakonfigurálnia. 300 postafiókkal ez megvalósíthatatlan. A küldési dátum szerinti rendezés nem megoldás, és a végfelhasználók nem értik, miért kell megváltoztatniuk a megszokott beállításaikat.

Az Outlook gyorsítótárának törlése vagy a profil újralétrehozása

Ez nem érinti a szerveren lévő INTERNALDATE-et. A profil újralétrehozása után az Outlook újraszinkronizálja az emaileket a szerverről, és pontosan ugyanazokat a sérült metaadatokat kapja vissza. A gyorsítótár nem a probléma.

OWA használata az Outlook helyett

Az OWA és az új Outlook ugyanazt az adatbázist használja. Ha az INTERNALDATE sérült az Exchange Online szerveren, az OWA pontosan ugyanolyan hibás dátumot jelenít meg. A kliens cseréje nem változtatja meg az adatokat.

A probléma a szerveren van, minden üzenet metaadataiban. Semmiféle kliensoldali beavatkozás nem képes szerveren tárolt adatokat javítani.

A Received fejlécek csapdája: miért bonyolítanak meg mindent

Amikor egy migrációs eszköz IMAP-on keresztül másol egy emailt egyik szerverről a másikra, a célszerver automatikusan hozzáad egy Received: fejlécet a lánc tetejére, az időbélyeggel együtt. Ez az RFC-kompatibilis SMTP- és IMAP-szerverek normális viselkedése.

Ezek a fejlécek fordított sorrendben halmozódnak fel az email által megtett út mentén. A legfrissebb van legfelül. Egyes levelezőprogramok az első Received: fejlécet olvassák a fogadási dátum becslésére, ami az eredeti dátum helyett a migrációs dátumot adja.

Pontosítás: ez a viselkedés nem egyetlen eszközre jellemző. A BitTitan MigrationWiz, a CloudM, az imapsync, a GSMMO, sőt még a két Thunderbird-kliens közötti kézi IMAP-másolás is ugyanezt az eredményt produkálja. Az eredeti Date: fejléc érintetlen marad az üzenetben. Pontosan ez teszi technikailag lehetővé a javítást. Az INTERNALDATE viszont egy különálló, szerver által kezelt metaadat, amelyet nem lehet pusztán az üzenet fejléceinek kliensoldali módosításával javítani.

Erről a mechanizmusról részletesebben az IMAP INTERNALDATE és a hibás dátumok cikk ír, amely bemutatja, hogyan kezeli ezt a metaadatot a különböző szerverek.

Mely migrációs eszközök okozzák ezt a problémát Microsoft 365-ben

A kérdés gyakran felmerül: minden migrációs eszköz okozza ezt a problémát?

A rövid válasz: a konfigurációtól és a célplatformtól függ. Az Exchange Online / Microsoft 365 szervere különösen szigorú az INTERNALDATE kezelésében. Még azok az eszközök is néha kudarcot vallanak, amelyek megpróbálják megőrizni, mivel a Graph API és az EWS (Exchange Web Services) különbözőképpen viselkedik az alkalmazott beillesztési módtól függően.

A BitTitan MigrationWiz az egyik legelterjedtebb eszköz a Microsoft 365-be való migrálásnál, és egyben az egyik, amelynek dátumproblémái a legjobban dokumentáltak. A BitTitan migrációs dátumok javítása a Microsoft 365-ben oldal tárgyalja a figyelendő specifikus konfigurációkat. A CloudM és az imapsync saját sajátosságaikkal rendelkeznek, amelyeket rendre a CloudM migrációs dátumok javítása a Microsoft 365-ben és az imapsync migrációs dátumok javítása a Microsoft 365-ben oldalak dokumentálnak.

Ami közös ezekben az eszközökben: az eredeti Date: fejléc túléli a migrációt. Ez az alap, amelyre egy javítás épülhet.

Miért rossz ötlet itt egy saját szkript

A probléma megértése néha azt az illúziót kelti, hogy a megoldás egyszerű. Nem az, nem éles üzemi méretben.

Az Exchange Online-on tárolt emailek metaadatainak módosítása nem triviális feladat. A Microsoft Graph API szigorú sebességkorlátokat szab meg (a 429 Too Many Requests hiba egy éjszakai kötegelt feldolgozásnál gyorsan felütheti a fejét). Az S/MIME-aláírt vagy PGP-titkosított emailek kezelése különös figyelmet igényel az aláírások érvénytelenítésének elkerülése érdekében. A nagy csatolmányokkal rendelkező multipart struktúrák hálózati időtúllépési korlátokat adnak hozzá. És ami a legfontosabb: hogyan ellenőrzöd email-ről emailre, hogy a javítás sikerült-e anélkül, hogy a tartalmat vagy a csatolmányokat megváltoztattad volna?

Egy szkript, amely 50 tesztemailnél jól fut, nem viselkedik majd ugyanúgy egy 40 000 üzenetes, 8 éves előzményekkel rendelkező postafiókban. A valószínűsége, hogy egy határeset elront valamit, minden egyes ezer üzenettel nő. Visszaállítási mechanizmus nélkül egy félúton bekövetkező hiba következetlen állapotban hagyja a postafiókot.

Lásd még: e-mail-dátumok javítása Microsoft 365 migráció után az elérhető lehetőségek átfogó áttekintéséhez.

Mit csinál konkrétan a Redate.io

A Redate.io úgy csatlakozik a Microsoft 365-höz, hogy mindenki a saját Microsoft-fiókjával jelentkezik be, és a Redate.io csak azt a postafiókot nyitja meg, amelyhez ez a bejelentkezés hozzáférést ad, ingyenesen átvizsgálja a hibás dátumú e-maileket, majd egy saját fejlesztésű javítómotort alkalmaz az azonosított üzenetekre. A többlépéses elemzési pipeline több száz ismert migrációs eszköz aláírásával végez egyeztetést, RFC-megfelelőségi ellenőrzést, és fejléclánc-elemzést végez a helyes dátummetaadatok rekonstruálásához.

Minden javított emailt külön-külön ellenőriz. A Redate.io soha nem törli az eredeti üzeneteket: azok a postafiók egy jól látható biztonsági mentési mappájában maradnak, amíg Ön maga nem törli őket. Az árazási modell egyszeri díj postafiókonként, előfizetés nélkül.

Az új Outlook ezután a helyes dátumokat mutatja, mert a szerveren lévő adatok javultak, nem csak el vannak rejtve.

Érintett postafiókjai vannak az új Outlookon? Indítson ingyenes vizsgálatot a Redate.io-n, hogy pontosan azonosíthassa, hány email érintett, mielőtt döntést hoz a következő lépésről.