Az Exchange IMAP-importok és az e-mail-dátumok
Az Exchange Online minden, egy postafiókba érkező üzenethez egy dátumot rendel, és ez az a dátum, amelyet az Outlook megjelenít, és amely szerint rendez. Egy internetről érkező e-mail esetében ez a kézbesítés pillanata. Egy migráció által bemásolt e-mail esetében az a dátum, amelyet a migráció a másolatnak adott: az eredeti, ha a migráció továbbadja azt, az import napja, ha nem.
Innen ered a rossz dátumok problémája az Exchange IMAP-importok során. Az Exchange Online nem írja felül a neki átadott dátumot. De ha egy import nem viszi át az egyes e-mailek eredeti dátumát, egy 7 éves üzenet másolata az import dátumát kapja, mintha az imént érkezett volna.
Az eredmény? Importál 4000 e-mailt egy régi IMAP-szerverről az Exchange Online-ba, és az e-mailek a saját dátumuk helyett az import dátumát mutatják. A 2018-as, 2020-as, 2023-as e-mailek mai dátummal jelennek meg. A felhasználók hétfő reggel megnyitják az Outlookot, és egy azonos dátumú üzenetekből álló falat látnak.
Hogyan működik az Exchange Admin Center migrációs varázslója
Az Exchange Admin Center (EAC) beépített migrációs varázslót tartalmaz az IMAP-importokhoz. Ez az a grafikus felület, amelyhez a legtöbb Exchange-rendszergazda először nyúl: a Recipients (Címzettek), majd a Migration (Migráció) menüpontba lép, új batch-et hoz létre, kiválasztja a "Migrate to Exchange Online" lehetőséget, forrásként az IMAP-ot választja, feltölt egy CSV-fájlt a postafiók-hozzárendelésekkel, és elindítja a batch-et.
A háttérben az EAC migrációs varázslója egy New-MigrationBatch parancsot hoz létre, amelynek végponttípusa IMAP-ra van állítva. Az Exchange kapcsolódik a forrás IMAP-szerverhez, beolvassa az egyes üzeneteket, és beírja azokat a cél Exchange Online postafiókba. Papíron egyszerű.
De itt van, amibe a rendszergazdák beleütköznek. A Microsoft nem dokumentálja, hogyan állítja be a migráció az egyes átmásolt üzenetek dátumát, és a rendszergazdák arról számolnak be, hogy az e-mailek az eredeti fogadás dátuma helyett a szinkronizálás dátumával jönnek ki. Az Outlook, az OWA és minden más, a postafiókhoz kapcsolódó kliens ezt a dátumot használja a megjelenítéshez és a rendezéshez.
A 2019-es eredeti Date: fejléc? Még megvan, elrejtve az üzenet fejlécei között. De az Exchange nem ezt használja a postafiók rendezési sorrendjéhez.
Date: Fri, 22 Nov 2019 16:08:33 +0100
PowerShell: New-MailboxImportRequest és ugyanaz a probléma
A parancssort előnyben részesítő rendszergazdák gyakran a New-MailboxImportRequest parancshoz nyúlnak PST-fájlok importálásához, vagy a New-MigrationBatch parancshoz IMAP-végpontokkal a szerverek közötti migrációkhoz. Az elvárás az, hogy a PowerShell nagyobb kontrollt ad. És bizonyos dolgokban valóban ad. A dátumok esetében nem.
A New-MailboxImportRequest PST-fájlokat importál Exchange Online postafiókokba. A PST-fájl tartalmazza minden üzenet eredeti időbélyegét. De a PowerShell parancsnak nincs olyan paramétere, amely irányítaná, hogy az egyes importált üzenetek milyen dátumot kapjanak. Nincs -PreserveDates jelző (és biztosan voltak rendszergazdák, akik kerestek egy ilyet).
New-MigrationBatch -SourceEndpoint IMAP-végponttal hasonlóan működik, mint az EAC varázslója, csak grafikus felület nélkül. Ugyanaz az IMAP-kapcsolat, ugyanaz az eredmény a dátumok tekintetében. A parancs kínál paramétereket dátumtartomány szerinti szűrésre (-StartAfter, -CompleteAfter) és mappák kizárására, de semmit, amely irányítaná, hogyan kezeli az Exchange a beérkező üzenet időbélyegét.
Pontosabban: ez elsősorban a megjelenítési dátumot és a rendezési sorrendet érinti. Az üzenet tartalma, beleértve az eredeti Date fejlécet, sértetlenül érkezik meg. Csak a másolatnak adott dátum hibás, és éppen ez áll mindannak a hátterében, amit a felhasználó lát.
Közvetlen IMAP-import vagy harmadik féltől származó eszközök
Számít, hogy az Exchange natív IMAP-importját használja, vagy egy harmadik féltől származó eszközt, mint a BitTitan MigrationWiz vagy a CloudM? A rövid válasz: a dátumprobléma mindkét esetben előfordul, de kissé eltérő okokból.
Az Exchange natív IMAP-importjával (EAC-varázsló vagy PowerShell) maga az Exchange kapcsolódik a forrás IMAP-szerverhez, és tölti le az üzeneteket. Az, hogy hogyan állítja be az egyes másolatok dátumát, a Microsofton múlik, és nincs dokumentálva.
Harmadik féltől származó eszközök esetén a migrációs eszköz közvetítőként működik. Beolvas a forrásból, esetleg átalakítja az üzenetet, és beírja az Exchange Online-ba. Amikor az eszköz IMAP-on keresztül ír, az Exchange Online megtartja az eszköz által átadott dátumot: ha az eszköz elküldi az egyes e-mailek eredeti dátumát, a másolat megtartja azt; ha nem, a másolat a migráció dátumát kapja. Néhány eszköz saját Received: fejlécet is hozzáad a továbbítás során.
A gyakorlati különbség? A visszamaradó fejlécek eszközről eszközre eltérnek, ezért egy javítás nem támaszkodhat egyetlen rögzített mintára. Az alapvető probléma azonos: a megjelenített dátum nem az e-mail eredeti dátuma.
Miért rontják a helyzetet az Exchange Online szállítási szabályai
Van itt valami, amivel még a tapasztalt Exchange-rendszergazdák is meglepődnek. Az Exchange Online-nak vannak szállítási szabályai (az admin centerben ma "mail flow rules"-nak, azaz levélfolyam-szabályoknak nevezik), amelyek az importált üzenetekre is aktiválódhatnak. Ha a szervezetnek vannak olyan szabályai, amelyek fejléceket illesztenek be, jogi nyilatkozatokat adnak hozzá, vagy feltételek alapján módosítják az üzeneteket, ezek a szabályok az importált e-maileket is feldolgozhatják.
Ez azt jelenti, hogy egy 2020-as e-mail lábjegyzetként jogi nyilatkozatot kaphat, vagy egy X-fejlécet, amelyet egy megfelelőségi szabály illesztett be, és amely nem is létezett, amikor az eredeti e-mailt elküldték. A hibás dátum a legláthatóbb tünet, de a szállítási szabályok további, nem várt módosításokat is okozhatnak.
Kikapcsolhatók a szállítási szabályok az import alatt? Igen, ideiglenesen. De a legtöbb rendszergazdának ez nem is jut eszébe, mert eleve nem számítanak arra, hogy a szállítási folyamat feldolgozza a migrált üzeneteket. Mire rájönnek, mi történt, az import batch már befejeződött, és a kár megtörtént.
Mit jelentenek a hibás dátumok az Exchange-környezetekben
Az Exchange-környezetek jellemzően üzleti környezetek. Ügyvédi irodák, pénzügyi intézmények, egészségügyi szervezetek, állami hivatalok. Ezek nem személyes Gmail-fiókok, ahol egy hibás dátum csak enyhén zavaró. Ezek olyan postafiókok, ahol az e-mailek időbélyegének jogi és szabályozási jelentősége van.
Az Exchange-ben egy jogi célú megőrzés (litigation hold) dátumtartományok alapján őrzi meg az e-maileket. Ha minden importált e-mail az eredeti dátum helyett az import dátumát mutatja, a megőrzés rossz üzeneteket rögzít. Egy eDiscovery-keresés a "2022. január és március közötti minden kommunikációra" nem ad eredményt, mert ezek az e-mailek most 2026 áprilisát mutatják.
A megőrzési irányelvek ugyanebbe a problémába futnak. Egy 3 éves megőrzési irányelvvel rendelkező szervezet véletlenül törölhet olyan e-maileket, amelyek 2026-osnak (és ezért "újnak") látszanak, miközben valójában 2019-esek, és meg kellene őrizni őket. Vagy éppen az ellenkezője: azok az e-mailek, amelyeket a megőrzési irányelv alapján már törölni kellett volna, megmaradnak, mert látszólagos dátumuk friss.
Egy 2025 végi eset: egy MSP körülbelül 200 postafiókot migrált egy hosztolt Exchange-szolgáltatótól a Microsoft 365-be az EAC migrációs varázslójával. Három héttel később az ügyfél megfelelőségi felelőse jelezte, hogy a negyedéves e-mail-archiválási jelentések minden archivált üzenetet ugyanazzal a dátummal mutattak. A teljes, 5 évre visszamenő e-mail-archívum úgy tűnt, mintha egyetlen novemberi kedden érkezett volna.
Az Exchange IMAP-import dátumainak javítása
Az eredeti Date: fejléc sértetlenül éli túl az importot. Az import nem módosítja az üzeneten belüli eredeti RFC 2822 fejléceket. Ez az eredeti dátum a javítás kiindulópontja.
A Redate.io csatlakozik az Exchange Online postafiókhoz (mindenki a saját Microsoft-fiókjával jelentkezik be), átvizsgálja az üzeneteket az IMAP-import okozta dátum-rendellenességek után, és egy saját fejlesztésű javítómotort alkalmaz, amely RFC-megfelelőségi ellenőrzést, az üzenetszerkezet megőrzését és célzott metaadat-helyreállítást végez. A Redate-nek nem kell tudnia, melyik eszköz végezte az importot: megtalálja azokat az e-maileket, amelyek megjelenített dátuma nem egyezik az eredeti dátumukkal.
Minden javított üzenet egyedileg ellenőrzésre kerül: a tartalom sértetlensége, a mellékletek ellenőrzőösszegei, a mappa-elhelyezés és a levelezési szálak. Az eredetik a saját postafiókjának egy látható biztonsági másolat mappájában maradnak, amíg Ön maga nem törli őket. Ha valami nem tűnik rendben lévőnek, a visszaállítás egy kattintásnyira van.
Miért nem egy PowerShell-szkripttel javítjuk meg? Mert a dátumprobléma megértése a könnyű rész. A nehéz rész az, hogy 8000 e-mailt javítsunk ki 50 postafiókban anélkül, hogy megsértenénk az S/MIME-mel aláírt üzeneteket, elrontanánk a beágyazott MIME-struktúrákat, összezavarnánk a nem ASCII RFC 2047 fejléceket, vagy elveszítenénk a mappa-hozzárendeléseket. Hogyan ellenőrzi, hogy egy produkciós környezetben minden egyes javított üzenet sértetlen, hogy nem veszett el melléklet, hogy nem szakadt meg levelezési szál? Egy szkript, amely egy 30 üzenetet tartalmazó teszt postafiókon működik, elakad a valós élet szélsőséges eseteinél. Az a szerződés egy 42 MB-os melléklettel és három beágyazott képpel, egy multipart/mixed struktúrába ágyazva egy multipart/alternative burkolaton belül? Sok sikert hozzá.
Platformspecifikus útmutatók
A dátumjavítás az Exchange Online postafiók szintjén történik, de a felhasználók különböző kliensekkel érik el az e-mailjeiket. Mindegyik másképp jeleníti meg a dátumokat:
- Exchange IMAP-import dátumainak javítása Outlookban
- Exchange IMAP-import dátumainak javítása OWA-ban (Outlook a weben)
Szélesebb körű áttekintést keres a Microsoft 365 dátumproblémáiról a különböző migrációs eszközök esetén? Nézze meg a teljes útmutatót az e-mail-dátumok javításához Microsoft 365 migráció után.
Az Exchange IMAP-import hibás dátumokkal hagyta a postafiókjait? Kezdje egy ingyenes átvizsgálással, hogy lássa, hány e-mailt érint a probléma és mennyibe kerül a javítás, bankkártya nélkül.