Outlook: IMAP migrációs dátum vs. elküldési dátum

A tünet, amelyet mindenki ismer

Befejezte az IMAP-migrációt Microsoft 365-re vagy Google Workspace-re. Hétfő reggel már gyűlnek a bejelentések: "Minden emailemnek ugyanaz a dátuma", "Tönkrement az előzményeim", "Semmit nem találok a postaládámban". Megnyitja az Outlookot, és valóban: több ezer email a múlt hétvégét mutatja. Nem azt, amikor küldték őket. Azt, amikor a migráció lezajlott.

Ez nem Outlook-hiba. Ez az IMAP-protokoll és a migrációs eszközök működésének közvetlen következménye. A megértéséhez azonban ki kell nyitni a motorháztetőt.

Három dátum egyetlen emailben

Egy email összetettebb, mint elsőre látszik. Fejléc, üzenettörzs, mellékletek... és több különböző időbélyeg, amelyek egymás mellett élnek. (Ha valaha megpróbálta elolvasni egy email nyers fejléceit, tudja, hogy az nem igazán tengerparti olvasnivaló.)

A Date: fejléc (RFC 2822)

Ez az a dátum, amelyet a küldő az elküldés pillanatában írt a levelébe. Az RFC 2822 szabvány határozza meg, és így néz ki:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Ez a fejléc bele van kőbe vésve az üzenetbe. Soha nem változik, hacsak valaki nem módosítja az üzenet nyers tartalmát. Ez a "küldési dátum" szó szerinti értelemben.

A Received: fejléc (minden hálózati ugráskor hozzáadódik)

Minden szerver, amely megérinti az átvitel közbeni emailt, egy Received: fejlécet illeszt az üzenet elejére, saját dátumával. Egy email, amely három szerveren halad át, három Received: fejlécet gyűjt össze. A legfrissebb mindig legelöl van. Valahogy így néz ki:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Az eredmény: amikor egy migrációs eszköz, például BitTitan MigrationWiz, CloudM, imapsync vagy GSMMO áthelyez egy emailt a forrásszerverről a célszerverre, maga is "hálózati ugrásként" viselkedik. Egy új Received: fejlécet szúr be a sor elejére, a migráció dátumával és időpontjával.

Az IMAP INTERNALDATE

Ez a harmadik dátum, és ez okozza a problémát. Az INTERNALDATE az IMAP-szerver oldalán tárolt metaadat, amely független az üzenet tartalmától. Azt jelöli, hogy mikor érkezett (vagy lett beillesztve) az email a postaládába. Amikor egy migrációs eszköz emailt szúr be, maga dönti el, milyen értéket kap az INTERNALDATE. Sok esetben az eszközök a migráció időpontját használják. Nem az eredeti dátumot.

Ennél a pontnál akad el minden.

Miért mutatja az Outlook a migrációs dátumot

Az Outlook az INTERNALDATE-et használja a "Fogadva" oszlop megjelenítéséhez. Ez az alapértelmezett viselkedése, és összhangban van az IMAP-specifikációval: az INTERNALDATE elvileg a postaládába érkezés dátumát jelöli. Normál körülmények között (amikor egy valódi email érkezik) az INTERNALDATE közel esik a Date: fejlécben lévő dátumhoz. A kettő összhangban van.

Egy sikertelen migráció után az összes importált email INTERNALDATE-e 2024. június 14-15. éjszakára (vagy bármilyen migrációs dátumra) mutat. Az Outlook beolvassa ezt az értéket, megjeleníti a "Fogadva" oszlopban, és az eredmény katasztrofális: 45 000 email látszólag ugyanazon az estén érkezett.

Pontosítás: az első (legfrissebb) Received: fejléc bizonyos konfigurációkban szintén befolyásolja a megjelenítést. De az INTERNALDATE marad a fő meghatározó az Outlook "Fogadva" oszlopában szinkronizált IMAP-módban.

Az "Elküldve oszlop hozzáadása" megkerülő megoldás Outlookban

Az első dolog, amit a legtöbb IT-adminisztrátor tesz a probléma felfedezésekor, hogy ügyféloldali kerülő megoldást keres. És valóban létezik ilyen.

Az Outlookban módosítható egy mappa oszlopnézete: a "Fogadva" oszlop helyett (vagy mellé) bevezethetjük a "Dátum" vagy "Elküldve" oszlopot. Ez az oszlop közvetlenül az üzenet Date: fejlécéből olvassa az értéket, nem az INTERNALDATE-ből. Mivel a migráció nem érintette a Date: fejlécet, az eredeti dátumok visszatérnek.

Outlookban (asztali verzió, Microsoft 365) ezt így lehet megtenni: jobb klikk az oszlopfejlécre az üzenetlistában, "Nézet beállításai", majd az oszlopok módosításánál távolítsa el a "Fogadva" oszlopot, és adja hozzá a "Dátum" oszlopot. Tömeges telepítéshez GPO-val is elvégezhető.

Rendben. Papíron megoldja a vizuális problémát. A valóságban ez egy sebtapasz egy artérián.

A megkerülő megoldás konkrét korlátai

Mobilos és webes kliensek

Az iOS-es, Android-os és webes Outlook (OWA) nem rendelkezik ugyanolyan testreszabási lehetőségekkel. A Windows-gépeken bevezetett nézeti módosítás nem terjed ki ezekre. Azok a felhasználók, akik telefonon olvassák az emailjeiket, továbbra is a migrációs dátumot látják. Egy közepes méretű cégnél ez valószínűleg a felhasználók fele.

A keresés

Az Outlook keresése a Windows Search indexet (vagy szerveroldalon az Exchange/Microsoft 365 indexet) használja. Ez az index az INTERNALDATE alapján épül fel, nem a Date: fejléc alapján. Ha egy felhasználó "2022. januári emailekre" keres, a keresés azokat az emaileket adja vissza, amelyeknek INTERNALDATE-e 2022 januárjára esik. Nem azokat, amelyek Date: fejlécében 2022. január szerepel. Következmény: a régi emailek eltűnnek a dátumszűrőkből. Az oszlopnézet megváltoztatása ezen nem segít.

Az emailszabályok

Az Outlook szabályai ("ha az email a következő dátum előtt érkezett...", "ha a következő dátum után érkezett...") szintén az INTERNALDATE-et használják. Egy dátumtartományon alapuló rendezési vagy archiválási szabály migráció után nem fog helyesen működni, ha az INTERNALDATE nem lett javítva.

Megfelelőség és eDiscovery

Ez talán a legsúlyosabb pont. A megfelelőségi, jogi archiválási és eDiscovery-eszközök (például a Microsoft Purview) az INTERNALDATE-et használják referenciadátumként a jogi lekérdezésekhez. Ha a vállalat megőrzési kötelezettségek alá esik, vagy discovery-megkeresésre kell válaszolnia, a sérült INTERNALDATE-ek komoly jogi problémákat okozhatnak. Egy audit, amely "adott két dátum közötti összes emailt" kéri, nem a helyes eredményeket fogja visszaadni.

Harmadik féltől származó eszközök

CRM-rendszerek, ticketing-eszközök, archiválók... minden, ami IMAP-on vagy a Microsoft 365/Google Workspace API-kon keresztül csatlakozik a levelezőszerverhez, az INTERNALDATE-et olvassa. Az Outlook-nézet módosítása ezeken a rendszereken semmit nem javít.

Az egyetlen valódi megoldás: szerveres szintű javítás

Az elküldési dátum szerinti rendezés Outlookban nem megoldás. Sebtapasz. A valódi javítást a szerver metaadatainak szintjén kell elvégezni, nem a kliens nézetében.

Ez konkrétan azt jelenti, hogy minden egyes email INTERNALDATE-ét korrigálni kell, hogy egyezzen az eredeti Date: fejléc dátumával. Az eredeti Date: fejléc mindig jelen van az üzenetben (a migráció nem törölte), tehát a javítás elvégezhető. Ott rejlik a valódi dátuminformáció.

Google Workspace esetén a Gmail API közvetlen hozzáférést biztosít az internalDate paraméterhez. Microsoft 365 esetén a mechanizmus eltér, de az elvárt eredmény ugyanaz. Szabványos IMAP-szerveren az üzenet beillesztésekor megadható a dátum.

A valóságban ezt az műveletet több tízezer éles emailen elvégezni, adatvesztés, duplikátumok, tönkrement szálak vagy elveszett mappák nélkül, miközben kezeli a határeseteket (S/MIME aláírt üzenetek, összetett MIME-struktúrák, RFC 2047 szerinti nem ASCII kódolások, nagyméretű mellékletek)... egészen más feladat. Egy szkript, amely 50 tesztemailen működik, 40 000 üzenetes éles postaládán nem fog teljesíteni. A 429-es hibaüzenetek (API-kvóta-túllépés) kezelése, az éjjel 2-kor bekövetkező hálózati timeoutok, a migráció során már részben megsérült MIME-struktúrájú üzenetek... mindez komoly mérnöki munkát igényel.

Pontosan ezt csinálja a Redate.io. A saját fejlesztésű javítómotor elemzi minden egyes email fejlécláncát, azonosítja a megbízható eredeti dátumot, és célzott metaadat-javítást alkalmaz anélkül, hogy hozzányúlna az üzenet tartalmához. Minden javított emailt egyenként ellenőriz. Az eredetiek 30 napig megmaradnak egy mentési mappában, ami biztosítja a visszaállítás lehetőségét. Olyasmi, amit egy házilagos szkript soha nem kínál.

A felelős migrációs eszköz azonosítása

A probléma ugyanúgy jelentkezik, függetlenül attól, honnan érkezett a migráció, de a részletek eltérnek az eszköz függvényében. A BitTitan MigrationWiz, a CloudM, az imapsync és a GSMMO mind saját "aláírást" hagynak az általuk injektált Received: fejlécekben. A Redate.io elemzési folyamata több száz ismert migrációs eszköz aláírásának adatbázisát tartja karban, hogy megkülönböztesse a migrációs fejlécet a legitim átviteli lánc többi elemétől.

Ha nem tudja, melyik eszközt használták a migrációhoz (ez előfordul, különösen ha egy másik MSP után veszi át a rendszert), a Redate.io ingyenes vizsgálata azonosítja az érintett postaládákat, és megbecsüli a javítandó mennyiséget, mielőtt bármilyen kötelezettséget vállalna.

Konkrét forgatókönyvekhez részletes útmutatók érhetők el: imapsync dátumok javítása az Outlookban, BitTitan dátumok javítása az Outlookban, vagy CloudM dátumok javítása az Outlookban.

Mi a teendő most?

Ha egy migráció után olvassa ezt a cikket, a jó hír az, hogy az eredeti Date: fejléc sértetlen minden egyes emailjében. A valódi dátuminformáció ott van, jelen van minden üzenetben. A probléma a metaadatokban van, nem a tartalomban. A metaadatok javíthatók.

Ha mélyebben szeretné megérteni a jelenség technikai hátterét, olvassa el az IMAP INTERNALDATE: miért hibásodnak meg a dátumok cikket, vagy az Outlook: rossz dátumok javítása migráció után átfogó útmutatót.

Készen áll a postaládák dátumainak javítására? Indítson ingyenes vizsgálatot a Redate.io-n, azonosítsa az érintett emaileket, és becsülje meg a javítandó mennyiséget, mielőtt bármilyen lépést tenne.