Tárhely-szolgáltató Microsoft 365-re: a rejtett dátumhiba

A probléma, amiről senki nem szólt

Végre befejezte az email-migráció t az OVH-ról, Infomaniak-ról, Ionos-ról vagy o2switch-ről Microsoft 365-re. Az EAC (Exchange Admin Center) migrációs varázslója egész éjjel futott, minden zöld, a postaládák tele vannak. Hétfő reggel az első support ticket: "Minden régi emailemnek mai dátuma van." Aztán jön a második. Majd tíz.

Ez nem a Microsoft 365 hibája. Nem is véletlen. Ez egy IMAP-migráció mechanikus következménye, és tárhely-szolgáltatóról való migráció esetén a probléma sokszor kétszer olyan súlyos, mint egy szokásos migrációnál. Nézzük meg, miért.

Hogyan kezeli az IMAP a dátumokat (és hol csúszik el minden)

Minden IMAP-szerveren tárolt emailnek kétféle dátumadata van. Az egyik az Date: fejléc (az RFC 2822 által meghatározott), amely magában az üzenetben szerepel, és azt jelzi, mikor küldték vagy kapták az üzenetet. A másik az INTERNALDATE, egy szerver szintű metaadat, amely azt rögzíti, mikor érkezett az üzenet a postaládába. Az email-kliensek, például az Outlook, alapértelmezés szerint ezt az értéket használják az emailek rendezéséhez és megjelenítéséhez.

(Egyébként ha valaha megpróbált nyers email-fejléceket olvasni az EAC-ban, tudja, hogy ez nem pontosan tengerparti olvasmány. Húsz-harminc fejlécsor is lehet a tényleges tartalom előtt.)

Amikor egy IMAP-migrációs eszköz átvesz egy üzenetet az egyik postaládából a másikba, újra létre kell hoznia ezt az INTERNALDATE-et a célszerveren. Egyes eszközök ezt helyesen végzik. Sok nem, vagy csak korlátozottan. A fogadó szerver a maga részéről megtartja, amit kap: ha egy másolat az eredeti dátumát hordozza, az Exchange Online megtartja azt a dátumot. Ha a dátumok hibásan jelennek meg, az eszközt kell megnézni, nem a Microsoft 365-öt.

Az eredmény: minden migrált email úgy néz ki, mintha a migráció napján érkezett volna. Mindegy, hogy 2019-ből származik.

A kétlépéses sérülés: miért súlyosbít minden a tárhely-szolgáltatóknál

Itt válik igazán problémássá a helyzet az olyan tárhely-szolgáltatókról érkező migráció esetén, mint az OVH, Infomaniak, Gandi, Ionos vagy o2switch.

Ezek a szolgáltatók általában megosztott Postfix, Dovecot vagy cPanel szervereket használnak, szabványos IMAP-konfigurációval. Sok kis- és középvállalkozás évek, esetleg 2010 vagy 2012 óta gyűjti itt az emailjeit. Amikor úgy döntenek, hogy átváltanak Microsoft 365-re, a migráció sokszor két lépésben zajlik.

1. lépés: az első sérülés (még a Microsoft 365 előtt)

Sok esetben az emailek már korábban átestek egy migráción. A cég az évek során egyszer-kétszer váltott tárhely-szolgáltatót: Ganditól OVH-ra 2018-ban, majd OVH-ról Infomaniak-ra 2022-ben, például. Minden egyes IMAP-átvitel visszaállíthatta az eredeti INTERNALDATE-et az átvitel napjára (ha az eszköz nem adta át az eredeti dátumot), és néhány eszköz saját migrációs fejléceket is hagyhat, az átvitel napjával dátumozva.

Amikor ezek az emailek megérkeznek a Microsoft 365-re, már "hegesedéseket" hordoznak. Az eredeti Date: fejléc érintetlen (az üzenet törzsének részét képezi, senki nem nyúl hozzá), de a dátum-metaadatokat már egyszer felborították.

2. lépés: a második sérülés az Exchange Online-ra való áttéréskor

Az EAC IMAP-migrációs eszköze, vagy egy külső eszköz, például a BitTitan MigrationWiz IMAP-módban beállítva, befogadja ezeket a már sérült emaileket. Ha ez az eszköz sem adja át az egyes emailek eredeti dátumát, az Exchange Online az átvitel napjára sorolja be az emailt, és az Outlook ezt a dátumot jeleníti meg "fogadási dátum"-ként.

Egy 2017 márciusában küldött email így akár két réteg hibás dátumot is hordozhat: a 2022-es migráció során hátrahagyott migrációs fejléceket, és a 2024-es Microsoft 365-re való migrációból származó fogadási dátumot. Az Outlook 2024-et mutat. A felhasználó 2024-et lát. Két szinten is téves.

Pontosítás: nem mindig szigorúan a legfrissebb Received: fejléc alapján dönt az Outlook. A megjelenített dátumot az Exchange Online által rögzített INTERNALDATE és a meglévő fejlécek kombinációja határozza meg. De amikor a migrációs eszköz nem adja át az eredeti dátumokat, a Microsoft 365-re való áttelepítés egy új hibaréteget hoz létre a régi tetejére.

Migrációs eszközök és tárhely-szolgáltatók: a kockázatos kombinációk

Megosztott tárhelyekről induló migrációknál néhány kombináció különösen gyakran szerepel:

• OVH / Infomaniak / Ionos + EAC IMAP-eszköz: a Microsoft natív eszköze kényelmes, de ismert arról, hogy tömeges IMAP-migrációknál nem megfelelően őrzi meg a dátumokat.
• cPanel (o2switch, LWS stb.) + BitTitan MigrationWiz IMAP-módban: a MigrationWiz IMAP-módban saját migrációs fejléceket ad hozzá. Ez az eredmény dokumentált, részletesen leírja a BitTitan migrációs dátumok javítása a Microsoft 365-ben oldal.
• Gandi / Mailcow + imapsync: az imapsync egy hatékony eszköz, de az INTERNALDATE kezelése a konfigurációtól függ. A megfelelő opció nélkül a dátumok nem maradnak meg. Lásd még: imapsync: nem maradtak meg a dátumok.
• Minden manuális, drag-and-drop alapú migráció Outlookban: ha valaki teljes mappákat másolt át két, Outlookban beállított fiók között fogd-és-vidd módszerrel, minden email INTERNALDATE-je felülíródott a másolás dátumával. Kivétel nélkül.

A közös nevező: mindezek a módszerek olyan emaileket juttatnak az Exchange Online-ba, amelyek Outlookban megjelenített dátuma már nem felel meg semmilyen valóságos időpontnak.

Miért veszélyes a "majd megoldom magam" szemlélet nagyobb léptékben

A problémát megérteni az egyik dolog. 8000 emailt javítani, amelyek 40 Exchange Online-postaládában találhatók, bonyolult mappastruktúrával, S/MIME-aláírással ellátott levelekkel, nagy mellékletekkel és egymásba ágyazott levelezési szálakkal, az egészen más lapra tartozik.

Egy PowerShell-szkript, amely tíz tesztemailnél látszólag működik, csendben meghiúsulhat a 4237. üzenetnél egy sérült MIME-határ vagy egy RFC 2047 szerint kódolt fejléc miatt (ez az a =?UTF-8?B?...?= formátum, amelyet a nem ASCII karakteres feladónevekben használnak). Egyedi ellenőrzési mechanizmus nélkül ezt soha nem veszi észre. Csak egy elveszett email marad utána.

Az ilyen típusú DIY-migráció konkrét kockázatai:

• Duplázódott üzenetek, ha a beillesztési logika félúton meghibásodik
• Hiányzó mellékletek, ha a multipart-struktúra rosszul épül újra
• Törött levelezési szálak az Outlookban (a szálak a References: és In-Reply-To: fejléceken alapulnak, amelyek sérülhetnek)
• 429-es hibák (Too Many Requests) a Microsoft Graph API-tól hajnali 3-kor, amelyek rollback nélkül leállítják a folyamatot
• Nincs egyszerű mód ellenőrizni, hogy mind a 8000 javítás helyesen lett-e alkalmazva

A tárhely-szolgáltatóról végzett migrációk esetén van egy további nehézség is: az emailek nem csak egy, hanem több réteg felesleges Received: fejlécet hordoznak. Egy egyszerű szkript, amely "az utolsó Received: fejlécet" távolítja el, nem elég. A teljes fejléclánc elemzésére van szükség ahhoz, hogy meghatározható legyen, melyik fejléc melyik migrációhoz tartozik, és melyik tükrözi valójában az eredeti fogadási dátumot.

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

A Redate.io minden felhasználó saját Microsoft-fiókjával történő bejelentkezésén keresztül nyitja meg az érintett postaládát, a bejelentkezéssel biztosított jogosultságokkal. A kezdeti scan ingyenes: a Redate.io azonosítja az összes olyan emailt, amelynek megjelenített dátuma nem egyezik a valódi dátummal, és postaládánként pontos becslést ad ezek számáról.

A javítás egy saját fejlesztésű motor segítségével zajlik, amely elemzi minden egyes üzenet teljes fejlécláncolatát, a használt migrációs eszköztől függetlenül, és helyesen rekonstruálja a dátum-metaadatokat, még akkor is, ha több réteg sérülés halmozódott fel. Minden javított emailt egyenként ellenőriz. A Redate.io soha nem törli az eredeti üzeneteket: azok egy jól látható biztonsági mentési mappában maradnak, amíg Ön maga nem törli őket.

A tárhely-szolgáltatókról érkező migrációknál a Redate.io többlépéses elemzési folyamata kifejezetten kezeli a kettős korrupció eseteit: nem pusztán az utolsó Received: fejlécet vizsgálja, hanem végigmegy a teljes előzményen, hogy megtalálja a tényleges fogadási dátumot. Általánosságban érdemes elolvasni az e-mail-dátumok javítása Microsoft 365 migráció után útmutatót, az alapvető mechanizmust pedig az IMAP INTERNALDATE: miért hibásodnak meg a dátumok cikk magyarázza el részletesen.

Migráció előtt vagy után: két lehetséges beavatkozási pont

Két helyzet, két megközelítés.

Még nem migrált. A jó hír: a károk korlátozhatók. Bizonyos migrációs eszközök (a MigrationWiz Exchange-módban, a CloudM megfelelő beállításokkal) jobban megőrzik a dátumokat, mint mások. De még a legjobb esetben is, egy nem tiszta előzményekkel rendelkező tárhely-szolgáltatóról induló migráció valószínűleg hagy majd nyomokat. Tervezze be a Redate.io-t a migráció után, még mielőtt átadja a postaládákat a felhasználóknak.

Már migrált, és jönnek a ticketek. A Redate.io a meglévő Microsoft 365-ös postaládákat is javítja, függetlenül attól, mikor zajlott a migráció. A scan pontos képet ad minden egyes postaláda valódi állapotáról, mielőtt bármilyen beavatkozás történne. Érdemes megnézni az email migráció ellenőrzőlistát is, hogy elkerülhesse ugyanezeket a problémákat a jövőben.

OVH-ról, Infomaniak-ról, Ionos-ról vagy o2switch-ről migrált Microsoft 365-re, és hibásak a dátumok? Hozzon létre egy Redate.io fiókot, scannelj le ingyenesen, és nézze meg pontosan, mekkora a kár, mielőtt bármit dönt.