Exchange IMAP import: miks e-kirjade kuupäevad on valed

Exchange IMAP importimine ja teie e-kirjade kuupäevad

Exchange Online annab igale postkastis olevale sõnumile kuupäeva, ja just selle kuupäeva järgi Outlook seda näitab ja sorteerib. Internetist saabuva e-kirja puhul on see kättetoimetamise hetk. Migratsiooni teel kopeeritud e-kirja puhul on see kuupäev, mille migratsioon koopiale andis: algne kuupäev, kui migratsioon selle edasi kannab, importimise päev, kui ei kanna.

Sellest tuleneb kuupäevade valesti kuvamine Exchange IMAP importide käigus. Exchange Online ei kirjuta üle kuupäeva, mille ta saab. Aga kui import ei kanna edasi iga e-kirja algset kuupäeva, saab 7 aasta vanuse sõnumi koopia importimise kuupäeva, nagu oleks see just kätte toimetatud.

Tulemus? Te impordite 4000 e-kirja vanast IMAP-serverist Exchange Online'isse, ja e-kirjad näitavad importimise kuupäeva oma tegeliku kuupäeva asemel. E-kirjad aastatest 2018, 2020, 2023, kuupäevaga täna. Teie kasutajad avavad esmaspäeva hommikul Outlooki ja näevad seina ühesuguse kuupäevaga sõnumitest.

Kuidas Exchange Admin Centeri migratsiooniviisard töötab

Exchange Admin Center (EAC) sisaldab sisseehitatud migratsiooniviisardit IMAP importide jaoks. See on graafiline liides, mille poole enamik Exchange administraatoreid kõigepealt pöördub: te lähete Saajad, seejärel Migratsioon, loote uue partii, valite "Migreeri Exchange Online'isse", valite lähtekohaks IMAP, laadite üles CSV-faili postkastide vastendustega ja käivitate partii.

Kulisside taga loob EAC migratsiooniviisard New-MigrationBatch käsuga lõpp-punkti tüübi IMAP peale seatuna. Exchange ühendub teie lähte-IMAP-serveriga, loeb iga sõnumi ja kirjutab selle siht-Exchange Online postkasti. Paberil piisavalt lihtne.

Aga siin on see, millega administraatorid kokku puutuvad. Microsoft ei dokumenteeri, kuidas migratsioon seab iga kopeeritud sõnumi kuupäeva, ja administraatorid teatavad e-kirjadest, mis tulevad välja sünkroonimise kuupäevaga, mitte kättesaamise kuupäevaga. Outlook, OWA ja kõik teised sellele postkastile ühendatud kliendid kasutavad seejärel seda kuupäeva kuvamiseks ja sorteerimiseks.

Algne Date: päis aastast 2019? Ikka olemas, peidus sõnumi päistes. Aga Exchange ei kasuta seda teie sisendkausta sorteerimisjärjestuse jaoks.

Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest ja sama probleem

Administraatorid, kes eelistavad käsurida, pöörduvad tihti New-MailboxImportRequest käsu poole PST-failide importimiseks, või New-MigrationBatch käsu poole IMAP lõpp-punktidega serverite vaheliste migratsioonide jaoks. Ootus on, et PowerShell annab rohkem kontrolli. Ja mõnes asjas annab. Kuupäevade puhul ei anna.

New-MailboxImportRequest impordib PST-failid Exchange Online postkastidesse. PST-fail sisaldab iga sõnumi algseid ajatempleid. Aga PowerShelli käsul ei ole parameetrit, mis kontrolliks, mis kuupäeva iga imporditud sõnum saab. -PreserveDates lippu ei ole olemas (ja uskuge mind, administraatorid on sellist otsinud).

New-MigrationBatch -SourceEndpoint IMAP lõpp-punktiga töötab sarnaselt EAC viisardiga, ainult graafilise liideseta. Sama IMAP-ühendus, sama tulemus kuupäevade osas. Käsk pakub parameetreid filtreerimiseks kuupäevavahemiku alusel (-StartAfter, -CompleteAfter) ja kaustade välistamiseks, aga mitte midagi, mis kontrolliks, kuidas Exchange käsitleb saabuva sõnumi ajatemplit.

Täpsuse huvides, see mõjutab peamiselt kuvatavat kuupäeva ja sorteerimisjärjestust. Sõnumi sisu, kaasa arvatud algne Date päis, jõuab kohale puutumatuna. Vale on ainult kuupäev, mille koopia sai, ja see on just see, mis peitub kõige nähtava taga kasutaja jaoks.

Otsene IMAP import versus kolmandate osapoolte tööriistad

On see oluline, kas kasutate Exchange'i sisseehitatud IMAP importi või kolmanda osapoole tööriista, näiteks BitTitan MigrationWiz või CloudM? Lühike vastus: kuupäevaprobleem tekib mõlemal juhul, aga veidi erinevatel põhjustel.

Exchange'i sisseehitatud IMAP importi puhul (EAC viisard või PowerShell) ühendub Exchange ise lähte-IMAP-serveriga ja tõmbab sõnumid. Kuidas ta seab iga koopia kuupäeva, otsustab Microsoft, ja see ei ole dokumenteeritud.

Kolmandate osapoolte tööriistade puhul tegutseb migratsioonitööriist vahendajana. Ta loeb lähtekohast, muudab võimalik et sõnumit, ja kirjutab Exchange Online'isse. Kui tööriist kirjutab IMAP kaudu, säilitab Exchange Online kuupäeva, mille tööriist edastab: kui tööriist saadab iga e-kirja algse kuupäeva, säilib see koopial; kui ei saada, saab koopia migratsiooni kuupäeva. Mõned tööriistad lisavad edastamise ajal ka omapoolse Received: päise.

Praktiline erinevus? Maha jäävad päised ei ole ühest tööriistast teise samad, seega ei saa parandus tugineda ühele kindlale mustrile. Aluseks olev probleem on identne: kuvatav kuupäev ei ole e-kirja algne kuupäev.

Miks Exchange Online'i transpordireeglid olukorda halvendavad

Siin on midagi, mis võtab isegi kogenud Exchange administraatorid ootamatult. Exchange Online'il on transpordireeglid (mida haldamiskeskuses nüüd nimetatakse "meilivoo reegliteks"), mis võivad aktiveeruda imporditud sõnumitel. Kui teie organisatsioonil on reeglid, mis lisavad päiseid, kinnitavad lahtiütlusi või muudavad sõnumeid tingimuste alusel, võivad need reeglid töödelda ka imporditud e-kirju.

See tähendab, et 2020. aasta e-kirjale võidakse lisada lahtiütluse jalus, või X-päis, mille lisab vastavusreegel, mida ei olnud olemas, kui algne e-kiri saadeti. Vale kuupäev on kõige nähtavam sümptom, aga transpordireeglid võivad tekitada täiendavaid ootamatuid muudatusi.

Saab transpordireeglid importimise ajaks välja lülitada? Jah, ajutiselt. Aga enamik administraatoreid ei mõtle selle peale, sest nad ei eelda, et transporditorustik migreeritud sõnumeid üldse töötleks. Selleks ajaks, kui nad mõistavad, mis juhtus, on importpartii lõpetatud ja kahju on tehtud.

Mida valed kuupäevad tähendavad Exchange keskkondades

Exchange keskkonnad on tavaliselt ärikeskkonnad. Advokaadibürood, finantsasutused, tervishoiuorganisatsioonid, valitsusasutused. Need ei ole personaalsed Gmaili kontod, kus vale kuupäev on kergelt tüütu. Need on postkastid, kus e-kirjade ajatemplitel on juriidiline ja regulatiivne tähtsus.

Õiguslik hoidmine (litigation hold) Exchange'is säilitab e-kirju kuupäevavahemike alusel. Kui iga imporditud e-kiri näitab importimise kuupäeva algse kuupäeva asemel, haarab hoidmine vale sõnumikomplekti. eDiscovery otsing "kõik suhtlused jaanuari ja märtsi 2022 vahel" ei tagasta midagi, sest need e-kirjad näitavad nüüd aprilli 2026.

Säilitamispoliitikad põrkuvad sama probleemiga. Organisatsioon, kellel on 3-aastane säilitamispoliitika, võib kogemata kustutada e-kirju, mis näivad olevat aastast 2026 (ja on seetõttu "uued"), kui need on tegelikult aastast 2019 ja peaksid säilima. Või vastupidi: e-kirjad, mis peaksid säilitamispoliitika alusel kustutatud olema, jäävad püsima, sest nende näiv kuupäev on värske.

Üks stsenaarium 2025. aasta lõpust: MSP migreeris umbes 200 postkasti majutatud Exchange teenusepakkujalt Microsoft 365-sse, kasutades EAC migratsiooniviisardit. Kolm nädalat hiljem märkas kliendi vastavusametnik, et kvartali e-kirjade arhiveerimise aruanded näitasid iga arhiveeritud sõnumi puhul sama kuupäeva. Terve e-kirjade arhiiv, mis ulatus 5 aasta taha, näis olevat saabunud ühel ja samal teisipäeval novembris.

Exchange IMAP importi kuupäevade parandamine

Algne Date: päis jääb importimise käigus puutumatuks. Import ei muuda sõnumi sisemisi algseid RFC 2822 päiseid. See algne kuupäev on parandamise lähtepunkt.

Redate.io ühendub Exchange Online postkastiga (igaüks logib sisse oma Microsofti kontoga), skannib sõnumeid, mille kuupäevades on IMAP importist tingitud anomaaliaid, ja rakendab Redate'i välja töötatud parandusmootorit, mis teeb RFC vastavuse kontrolli, säilitab sõnumi struktuuri ja teeb sihitud metaandmete taastamise. Redate'il ei ole vaja teada, milline tööriist importi teostas: see leiab e-kirjad, mille kuvatav kuupäev ei vasta nende algsele kuupäevale.

Iga parandatud sõnum kontrollitakse üksikult: sisu terviklikkus, manuste kontrollsummad, kausta asukoht ja vestlusahelad. Originaalid jäävad teie postkasti nähtavasse varukoopia kausta, kuni te need ise kustutate. Kui midagi näib vale, on tagasipööramine ühe klõpsu kaugusel.

Miks mitte parandada seda PowerShelli skriptiga? Sest Received päise probleemi mõistmine on kerge osa. 8000 e-kirja parandamine 50 postkasti ulatuses, ilma S/MIME allkirjastatud sõnumeid rikkumata, pesastatud MIME struktuure lõhkumata, mitte-ASCII RFC 2047 päiseid moonutamata või kaustade määranguid kaotamata, on raske osa. Kuidas kontrollida, et iga üksik parandatud sõnum tootmiskeskkonnas on terve, et ühtegi manust ei kaotatud, et ühtegi vestlusahelat ei rikutud? Skript, mis töötab testpostkastis 30 sõnumiga, jookseb reaalse maailma erijuhtumite peale kinni. See leping 42 MB manusega ja kolme sisestatud pildiga, mis on põimitud multipart/mixed struktuuri sees multipart/alternative ümbrise sisse? Edu.

Platvormispetsiifilised juhendid

Kuupäeva parandus toimub Exchange Online postkasti tasandil, aga kasutajad pääsevad oma e-kirjadele ligi erinevate klientide kaudu. Igaüks kuvab kuupäevi erinevalt:

• Parandage Exchange IMAP importi kuupäevad Outlookis
• Parandage Exchange IMAP importi kuupäevad OWA-s (Outlook veebis)

Otsite laiemat konteksti Microsoft 365 kuupäevaprobleemide kohta erinevate migratsioonitööriistade lõikes? Vaadake täielikku juhendit e-kirjade kuupäevade parandamiseks pärast Microsoft 365 migratsiooni.

Exchange IMAP import jättis teie postkastid valede kuupäevadega? Alustage tasuta skaneerimisega, et näha, mitu e-kirja on mõjutatud ja mis parandus maksab, krediitkaarti ei vajata.