iCloud-ból Office 365-be: rossz email dátumok

Egy migrációs forgatókönyv, amely szisztematikusan elrontja a dátumokat

Befejezte az iCloud Mail-ből Office 365-be való átvitelt. Az emailek megvannak, a mappák a helyükön, minden rendbennek tűnik. Hétfő reggel megérkezik az első panasz: "Minden régi emailem a mai dátumot mutatja." Aztán egy második. Aztán tíz.

Ez nem egyedi hiba. Az iCloud Mail-ből Office 365-be való migráció az egyik legjobban dokumentált dátumkorrupciós forgatókönyv, egészen pontos technikai okok miatt, amelyek az Apple Mail viselkedéséhez, az IMAP protokollhoz és ahhoz kapcsolódnak, ahogyan a Microsoft 365 kezeli a beérkező üzeneteket.

Miért rontja el az iCloud-ból Office 365-be való migráció a dátumokat

A probléma megértéséhez el kell különíteni három dolgot, amelyet sokan összekevernek (köztük tapasztalt IT adminok is): a Date: fejlécet, az IMAP INTERNALDATE-et és a fájl létrehozási dátumát.

A Date: fejléc (RFC 2822)

Minden email tartalmaz egy Date: fejlécet, amely jelzi, mikor küldték az üzenetet. Ez a fejléc be van ágyazva az üzenet nyers törzsébe, és elméletileg soha nem változik. Ez az "eredeti" dátum a szó legszorosabb értelmében.

Az IMAP INTERNALDATE

Az IMAP protokoll (amelyet az RFC 3501 definiál) minden üzenethez társít egy különálló metaadatot, az INTERNALDATE-et. Ezt az értéket használja a legtöbb levelezőprogram az üzenetek rendezéséhez és megjelenítéséhez a beérkező mappában, nem a Date: fejlécet. Az Outlook különösen erősen támaszkodik az INTERNALDATE-re a megjelenítéshez és a rendezéshez.

Mi a gond? Amikor egy migrációs eszköz egy IMAP-szerverről a másikra másol egy emailt, ideális esetben meg kellene őriznie ezt az INTERNALDATE-et. A gyakorlatban ez nem mindig így történik.

Az Apple Mail különleges viselkedése

Az Apple Mail az iCloudból szinkronizált üzeneteknél néha a szerveren lévő fájl létrehozási dátumát használja az INTERNALDATE referenciaértékeként. Ez nem bug a szó szoros értelmében, hanem az IMAP specifikáció olyan értelmezése, amely eltér attól, amit más levelezőprogramok csinálnak. (Egyébként ha valaha próbált INTERNALDATE-problémát debugolni nyers IMAP RFC-ket olvasva, tudja, hogy a specifikáció elég tág értelmezési teret hagy ezen a ponton.)

Eredmény: amikor az Apple Mailen keresztül exportál vagy migrál iCloudból, az üzenetek INTERNALDATE-jei már helytelenek lehetnek, mielőtt még elérnék az Office 365-öt.

Az iCloud migráció három módszere és buktatói

Közvetlen IMAP migráció

A leggyakoribb módszer: az iCloudot IMAP-forrásként, az Office 365-öt célként konfigurálja, majd migrációs eszközt használ (imapsync, MigrationWiz vagy saját fejlesztés). Az eszköz csatlakozik mindkét szerverhez és lemásolja az üzeneteket.

A probléma itt kétszeres. Egyrészt az Apple IMAP-szervereinek sebességkorlátozásai arra kényszerítik az eszközöket, hogy szüneteket tartsanak, ami olyan időablakokat teremt, ahol a kapcsolatok bezáródnak és újranyílnak, és ez parazita INTERNALDATE-eket generálhat. Másrészt minden, IMAP APPEND paranccsal Exchange Online-ra másolt üzenet alapértelmezés szerint a migráció időpontját kapja beérkezési dátumként, kivéve ha az eszköz kifejezetten átadja az eredeti INTERNALDATE-et az INSERT parancsban.

Néhány eszköz ezt helyesen csinálja. Mások nem következetesen. Egy 40 000 üzenetes postaládában még 2%-os hibaarány is 800 rosszul dátumozott emailt jelent.

Az imapsync általi migrációkhoz lásd még: imapsync migrációs dátumok javítása a Microsoft 365-ben.

.mbox vagy .eml export, majd import

Egyes felhasználók az Apple Mail-lel exportálják az iCloud emailjeiket .mbox formátumba, majd megpróbálják importálni Outlookba. Ez egy kézzel összerakott módszer, amely változó eredményeket produkál.

A .mbox formátum szöveges üzenetek sorozataként kódolja az emaileket. A dátumok jelen vannak az egyedi Date: fejlécekben, de az üzenetek közötti elválasztó sor ("From ") tartalmaz egy dátumot, amelyet egyes importálók létrehozási dátumként értelmezhetnek. Az Outlook, amikor .pst-vé konvertált .mbox-ot importál, néha ezt az elválasztó dátumot használja az üzenet saját Date: fejléce helyett.

Húzás-ejtés Outlookon keresztül

Ez a módszer okozza a legtöbb kárt. A felhasználó mindkét fiókot konfigurálja az Outlookban (iCloud és Office 365), majd mappából mappába húzza az üzeneteket. Egyszerűnek tűnik. A dátumok szempontjából katasztrófa.

Amikor az Outlook két IMAP-fiók között húz-ejt egy üzenetet, valójában új .EML fájlt generál, beilleszti a célfiókon, és törli az eredetit. Ez az új fájl a Windows fájl létrehozási dátumát örökli, vagyis a húzás-ejtés pontos pillanatát. Az eredeti Date: fejléc mindig jelen van az üzenet törzsében, de az Exchange Online szerverén rögzített INTERNALDATE a manipuláció dátumának felel meg. Az Outlook ezt a migrációs dátumot jeleníti meg ezután minden áthelyezett üzenetnél.

Pontosabban fogalmazva, ez a viselkedés Outlook verziónként eltér. A 2023 őszi Outlook-frissítés óta egyes esetekben kissé javult a helyzet, de a fiókok közötti húzás-ejtés dokumentáltan dátumkorrupciós forrás maradt.

Mit mutat végül az Office 365 és az Outlook

Az Exchange Online az INTERNALDATE-tel együtt tárolja az emaileket. Az Outlook Desktop ezt az INTERNALDATE-et olvassa, hogy megjelenítse a dátumot a "Fogadva" oszlopban és rendezze a beérkező mappát. Ha az INTERNALDATE a migráció során felülírásra került, az Outlook a migráció dátumát mutatja, és kész.

Az Outlook Web App (OWA) ugyanígy működik. Nincs olyan "alternatív nézet", amely az eredeti Date: fejléc dátumát mutatná. Amit a dátum oszlopban lát, az az INTERNALDATE.

Az eredeti Date: fejléc ott van, érintetlenül, olvasható, ha megjeleníti az üzenet nyers fejléceit. De egyetlen normál nézet sem mutatja. Ez a probléma központi frusztrációja: a helyes információ létezik, csak technikai javítás nélkül nem elérhető.

Amit a Microsoft support nem old meg

Ha megnyit egy Microsoft Support ticketet ezzel a problémával, valószínűleg ezt fogja kapni: megerősítést, hogy a megjelenített dátumok a tárolt INTERNALDATE-eknek felelnek meg, javaslatot az Outlook rendezési beállításainak ellenőrzésére, és esetleg visszairányítást a használt migrációs eszközhöz.

Ez nem rosszindulat. A Microsoftnak egyszerűen nincs natív eszköze az Exchange Online-ba már befogadott több ezer üzenet INTERNALDATE-jeinek utólagos javítására. A javítás egyenként megköveteli az üzenetekhez való hozzáférést, fejléceik elemzését és a dátum metaadatok rekonstrukcióját, ami kívül esik a standard support hatáskörén.

Az iCloud support azt tekinti, hogy az üzenetek helyesen lettek exportálva, és a probléma a céloldalon van. A két support egymásra mutogat, a felhasználó pedig ott marad 12 000, a migráció napjára dátumozott emaillel.

A méretarány problémája

Megérteni, miért romlottak el a dátumok, az egyik dolog. Manuálisan javítani őket egy éles postaládában, az egészen más.

Néhány IT admin szkripttel próbálja megoldani a javítást. Az alapötlet nem bonyolult konceptuálisan, de valós volumeneken az önkészítésű szkriptek rosszul kezelik a következő problémákat:

• Az S/MIME-mel aláírt vagy PGP-vel titkosított emailek nem módosíthatók a kriptográfiai aláírás érvénytelenítése nélkül
• A komplex multipart/alternative struktúrájú üzenetek (HTML + egyszerű szöveg + beágyazott mellékletek) manipulálása törékeny
• A nem ASCII-ban kódolt fejlécek (RFC 2047, különösen japán, arab vagy cirill karaktereknél) megrongálódhatnak az ezeket nem megfelelően kezelő eszközökkel
• A Microsoft Graph API-kvótái és az Exchange Online sebességkorlátozásai (429 Too Many Requests hiba) megállítják az exponenciális visszalépés kezelésére nem tervezett szkripteket
• Egy 500 teszt emailen helyesen futó szkript hajnali 3-kor leáll egy valódi postaláda 8000. üzeneténél, folytatási mechanizmus nélkül

És a döntő kérdés: hogyan ellenőrzi, hogy minden javított email sértetlen a javítás után? Hogy a melléklet még mindig ott van? Hogy a levelezési szál nem tört el? Egy házi szkript általában nem végzi el ezt az ellenőrzést.

Hogyan kezeli a Redate.io az iCloud-ból Office 365-be való migrációkat

A Redate.io közvetlenül az Office 365-höz csatlakozik a Microsoft 365 engedélyeken keresztül (Azure AD), anélkül hogy hozzáférést igényelne az iCloud-szerverekhez. Az emailek már az Exchange Online-on vannak, amikor a Redate beavatkozik.

A Redate javítómotorja minden üzenet fejlécláncát elemzi az eredeti dátum azonosításához, megkülönböztetve a migráció során hozzáadott Received: fejléceket a legitim dátum metaadatoktól. Ez az elemzés mintaegyeztetést végez több száz ismert migrációs eszköz aláírásán, ami lehetővé teszi a parazita fejlécek azonosítását még akkor is, ha azok nem nyilvánvalóak első ránézésre.

Minden javított emailt egyedileg ellenőriz a feldolgozás után. Az eredetik egy látható biztonsági másolat mappában maradnak 30 napig, amit egyetlen házi szkript sem tesz meg alapértelmezés szerint. A kezdeti szkennelés ingyenes, és lehetővé teszi az érintett emailek pontos számának meghatározását a javítási döntés előtt.

A Redate.io a Google Workspace-ből Office 365-be való migrációkat és cPanel utáni javításokat is támogatja. Lásd például: email dátumok javítása Microsoft 365 migráció után vagy hibás email dátumok Exchange Online migráció után.

Először szkennelés, utána javítás

Az ajánlott kiindulópont minden olyan iCloud-ból Office 365-be való migrációhoz, amely helytelen dátumokat eredményezett: futtassa a Redate.io ingyenes szkennelését az érintett postaládákon. A szkennelés pontosan azonosítja, hány emailnek van gyanús INTERNALDATE-je és melyik mappákban találhatók.

Ez 12 és 45 perc között telik el a volumentől függően, és tiszta képet ad a probléma kiterjedéséről bármilyen beavatkozás előtt. Az MSP-k számára, akik migráció után egyszerre több postaládát kezelnek, ez a kötegelt szkennelés elkerüli, hogy olyan postaládákat is javítsanak, amelyeknek arra nincs szükségük.

Ha az emailek dátuma helytelen az iCloudból való migráció után, kezdje az ingyenes Redate.io-szkennelással, hogy felmérje a probléma mértékét az Office 365-ös postaládáin.