Hibás email dátumok Exchange Online migráció után

A klasszikus hétfő reggeli forgatókönyv

Befejezte az IMAP-ról Exchange Online-ra való migrációt. A batch az Exchange felügyeleti központban (EAC) hiba nélkül lefutott, a postaládák szinkronizálva vannak, a felhasználók be tudnak lépni. Pénteken este lecsukja a laptopot, elégedett: a munka kész.

Hétfőn reggel megkezdődnek a bejelentések. "Minden emailem pénteki dátumot mutat." "A beérkező leveleim előzménye használhatatlan." "Hiányoznak a régi emailek." Valójában semmi sem hiányzik: az emailek ott vannak, de az Outlook mindegyiket a migráció dátumával jeleníti meg az eredeti küldési dátum helyett. Egy 2019-es email úgy jelenik meg, mintha múlt pénteken érkezett volna. Az eredmény: az egész postaláda csupa friss üzenetet tartalmaz látszólag.

Ez az egyik legfrusztrálóbb probléma az Exchange Online IMAP-migrációknál, és a Microsoft szinte rendszeresen aluldokumentálja.

Miért rontja el a dátumokat az EAC-on keresztüli migráció

Amikor az Exchange felügyeleti központot (EAC) használja IMAP-migráció konfigurálásához egy helyi szerverről (Dovecot, Courier, Cyrus, UW-IMAP, mindegy melyik), az Exchange Online IMAP-on keresztül csatlakozik a forráskiszolgálóhoz, lekéri az üzeneteket, majd a saját belső átviteli csővezetékén keresztül injektálja azokat a célpostaládákba.

Ez az a pont, ahol a probléma keletkezik.

Minden üzenet, amely átmegy az Exchange átviteli csővezetékén, automatikusan kap egy időbélyegzett Received: fejlécet. Ez évtizedek óta standard viselkedése az SMTP- és IMAP-kiszolgálóknak: minden szerver, amely hozzányúl egy üzenethez, rábélyegzi a saját időbélyegét. A probléma az, hogy az Outlook (különösen a Windows-os Outlook újabb verzióiban) a legutóbbi Received: fejlécet használja megjelenítési hivatkozásként, ha más metaadatok kétértelmuek.

Az eredeti Date: fejléc (amelyik azt jelzi, mikor küldték valóban az emailt, az RFC 2822 értelmében) mindig jelen van az üzenetben. Nem törlődött. De "elhomályosítja" az Exchange által az injektáláskor hozzáadott új Received: fejléc.

Emellett az IMAP INTERNALDATE (az a metaadat, amelyet az IMAP-kiszolgálók az üzenetek belső dátumozásához használnak, és amely a legtöbb kliensnél a rendezést vezérli) az injektálás dátumára kerül, nem az email eredeti dátumára. Az Exchange Online-nak nincs natív módja az INTERNALDATE megőrzésére a forráskiszolgálóról az EAC-on keresztüli batch-migráció során.

EAC vs. harmadik féltől származó eszközök: fontos különbség

Két helyzetet kell megkülönböztetni. Olyan eszközöknél, mint a BitTitan MigrationWiz vagy a CloudM Migrate, a probléma szintén fennáll, de ezeknek az eszközöknek néha vannak konfigurációs lehetőségeik (részlegesen dokumentálva, gyakran elrejtve a haladó beállításokban), amelyek megpróbálják megőrizni bizonyos dátum-metaadatokat.

Az EAC-on keresztüli natív migráció viszont egyáltalán nem kínál ilyen lehetőséget. A Microsoft nem tesz közzé paramétert az INTERNALDATE megőrzésének vezérléséhez a batch-migrációs csővezetékben. Ez egy fekete doboz: konfigurálja a batch-et, elindítja, az Exchange belső ügyei szerint jár el. És amit rendszeresen csinál: az üzeneteket az injektálás dátumával látja el.

(Ha egyébként valaha is megpróbálta elolvasni egy EAC-on keresztül migrált email nyers fejléceit, felismeri az Exchange által hozzáadott Received: mezőt: tartalmaz hivatkozásokat a Microsoft belső kiszolgálóira, mint például *.protection.outlook.com vagy *.prod.exchangelabs.com, egy olyan időbélyeggel, amely pontosan a migrációs ablaknak felel meg.)

Miért nem old meg semmit a batch újraindítása

Sok IT-adminisztrátor ösztönös reakciója erre a problémára: "Ha törlöm a migrált postaládákat, és nulláról újraindítom a batch-et, talán most helyesek lesznek a dátumok."

Érthető. De nem működik.

A probléma nem a batch konfigurációjában rejlik. Nem egy beállításban, amelyet elfelejtettünk bejelölni. Az Exchange átviteli csővezetékének architektúrájában van, amely minden migráció esetén azonos. A batch újraindítása pontosan ugyanazt az eredményt hozza: ugyanazokat a Received: fejléceket az új migráció dátumával, és ugyanazokat a helytelen INTERNALDATE értékeket. Időt veszít, és a felhasználókat másodszor is megzavarja, feleslegesen.

Egyes adminisztrátorok az Outlookban próbálkoznak a rendezési beállítások módosításával ("rendezés küldés dátuma szerint" a "fogadás dátuma" helyett). A küldési dátum szerinti rendezés nem megoldás. Tapasz a sebre. A Date: fejléc és az INTERNALDATE továbbra is helytelen marad azon klienseknél, amelyek nem teszik lehetővé ezt a beállítást, az OWA-ban, az Outlook Mobile-ban, valamint minden olyan harmadik féltől származó alkalmazásban, amely IMAP-on vagy EWS-en keresztül fér hozzá a postaládához.

Mi történik valójában a fejlécekben

Íme egy egyszerűsített példa arra, mit tartalmaz egy email az EAC-on keresztüli migráció után. Az eredeti fejléc:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@regidomainnev.hu
Subject: Q1 2019 Jelentés

A migráció után az üzenet a fejlécsorozat elejére kap valami ilyesmit:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Az Outlook ezt a Received: fejlécet látja elsőnek (a fejlécblokk tetejére kerül), az üzenet legutóbbi feldolgozási dátumaként értelmezi, és fogadási dátumként jeleníti meg. Az eredeti 2019-es Date: fejléc ott van, érintetlenül, néhány sorral lejjebb. De az Outlook nem azt használja az üzenetlista megjelenítéséhez.

Pontosabban fogalmazva: a viselkedés kissé eltér az Outlook-verziók között. A 2021 utáni verziók (és különösen a 2023 vége óta kitelepített új Windows-os Outlook) különösen érzékenyek erre a problémára, mert inkább az Exchange Graph-metaadatokra támaszkodnak, mint a nyers Date: fejlécre. Ez azt jelenti, hogy az Outlook 2016-tal nem okozott látható problémát migrációk az új Outlookkal már gondot okozhatnak.

Kit érint valóban a probléma

Az ilyen típusú migrációknál leggyakoribb IMAP-forráskiszolgálók a Dovecot (nagyon elterjedt Linux/cPanel környezetben) és a Courier. Mindkettő IMAP-on keresztül teszi közzé az INTERNALDATE értékeket, amelyeket az EAC nem őriz meg. Ha helyi Exchange-kiszolgálóról migrál Exchange Online-ra (hibrid vagy átvágásos migráció), a viselkedés más, mert a Microsoft egy belső átviteli protokollt (MAPI/EWS) használ, amely jobban megőrzi a metaadatokat. Az EAC-on keresztüli általános IMAP-migráció az, amelyik problémát okoz.

A legjobban érintett felhasználók azok, akiknek hosszú előzménnyel (5 évnél több) és nagy mennyiségű üzenettel rendelkező postaládájuk van. Egy 300 emailes postaládával rendelkező felhasználó gyorsan felépül. Egy kereskedelmi igazgató, akinek 12 000 emailje van dátum szerint rendezve, és napi szinten tőlük függ az ügyféllevelezés visszakereséséhez, az megbénul.

Miért rossz ötlet itt egy házilagos szkript

Azok az IT-adminisztrátorok, akik megértik a technikai problémát, kísértésbe esnek, hogy PowerShell- vagy Python-szkriptet írjanak a fejlécek manuális javítására. Az alapkoncepció egyszerűnek tűnhet, ha már azonosítottuk a mechanizmust. De egy éles környezetbeli javítás valósága egészen más történet.

Először is: a határesetek. Az S/MIME-aláírással ellátott emailek és a PGP-titkosított üzenetek olyan struktúrával rendelkeznek, amely nem tűri a fejlécek módosítását az aláírás érvénytelenítése nélkül. A rosszul formázott MIME-határokkal rendelkező multipart/alternative üzenetek (amelyek gyakoriak a régi Courier-kiszolgálókon) megsérülhetnek egy olyan szkripttől, amely nem építi újra megfelelően a struktúrát. Az RFC 2047 szerint kódolt nem ASCII fejlécek (pl. ékezetes vagy japán karaktereket tartalmazó feladónevek) klasszikus hibaforrások.

Aztán ott van a mennyiség. Egy szkript, amely 50 tesztemail esetén működik fejlesztői környezetben, nem kezeli az Exchange Online API sebességkorlátozásait éles környezetben. A 429 Too Many Requests hiba hajnali 2-kor, egy 8000 üzenetből álló batch közepén, újraindítási mechanizmus nélkül: egy álmatlan éjszaka, és esetleg duplikált vagy elveszett üzenetek.

És a legfontosabb: hogyan ellenőrizhető, hogy minden javított email sértetlen? Hogy egyetlen melléklet sem csonkult meg, egyetlen levelezési szál sem tört el, a mappák és feliratok megmaradtak? Egyéni validációs mechanizmus nélkül az ember csak reménykedik, hogy minden rendben ment.

A migrációs dátumok javítása olyan probléma, amely 50 soros szkriptnek tűnik, de megbízható éles működéshez több ezer sort igényel.

Mit csinál másképp a Redate.io

A Redate.io a Microsoft 365 API-jain keresztül csatlakozik az Exchange Online-hoz (Azure Active Directory, bérlői szintű delegált engedélyek), és megvizsgálja az érintett postaládákat, hogy azonosítsa azokat az emaileket, amelyek dátum-metaadatait a migráció megsértette. Ez az ellenőrzési lépés ingyenes, és pontos képet ad a probléma kiterjedéséről: érintett üzenetek száma, érintett postaládák, sérült dátumok tartománya.

A Redate.io saját fejlesztésű javítási motorja ezután egyenként dolgozza fel az emaileket egy többlépéses elemzési csővezetéken keresztül, amely magában foglalja az ismert migrációs eszközök (köztük az Exchange Online átviteli csővezetéke) aláírásainak mintaillesztését, RFC-megfelelőségi ellenőrzést, valamint az üzenet szerkezeti integritásának ellenőrzését a javítás előtt és után. Az S/MIME-aláírással ellátott emailek, az összetett MIME-struktúrák, a nem szabványos kódolások: mindegyiket specifikus feldolgozási útvonalakon kezeli.

Minden javított üzenetet egyedileg ellenőrizzük. Az eredetiek 30 napig látható biztonsági mentési mappában maradnak. Ha egy adott üzenettel valami nem stimmel, nem módosítja: a Redate.io jelzi a rendellenességet, ahelyett hogy kockáztatna egy esetleges sérülést.

Az árazás mennyiségen alapul, postaládánkénti egyszeri fizetéssel. Nincs előfizetés, nincsenek ismétlődő díjak. A problémát egyszer javítja meg, kész.

Az Exchange Online migrációknál a Redate.io az Azure AD alkalmazásengedélyeken keresztül kezeli a kapcsolódást (anélkül, hogy postaládánként külön hitelesítő adatokat kellene létrehozni), ami nagyobb postaláda-flották feldolgozását sokkal egyszerűbbé teszi egy IT-adminisztrátor vagy MSP számára.

Ha több, ilyen típusú migrációt elszenvedett ügyfelet kezel, tekintse meg az Exchange Online migrációs dátumjavításról szóló átfogó útmutatót is a különböző forgatókönyvek áttekintéséhez.

Az emailek ott vannak, az eredeti dátumok is. Indítson ingyenes ellenőrzést a Redate.io-n, és nézze meg pontosan, hány üzenet érintett az Exchange Online postaládáiban, mielőtt dönt a teendőkről.