Valed e-kirjade kuupäevad pärast Exchange Online'i migratsiooni

Klassikaline esmaspäeva hommik

Migratsioon on lõpetatud. IMAP-batch lõppes Exchange'i halduskeskuses veata, postkastid on sünkroniseeritud, kasutajad saavad sisse logida. Sulgete arvuti reedel õhtul rahuliku südamega.

Esmaspäeval hakkavad tikettid tulema. "Kõik minu e-kirjad on dateeritud reedega." "Mu sisendkasti ajalugu on kasutuskõlbmatu." "Vanad kirjad on kadunud." Tegelikult pole midagi kadunud: kirjad on olemas, kuid Outlook kuvab kõiki neid migratsioonikuupäevaga, mitte algse saatmiskuupäevaga. 2019. aasta e-kiri näib dateerituna eelmise reedega. Tulemus: kogu postkast näib sisaldavat ainult hiljutisi sõnumeid.

See on üks ärritavamaid probleeme IMAP-migratsioonil Exchange Online'i, ja Microsoft dokumenteerib seda süstemaatiliselt liiga vähe.

Miks EAC kaudu migratsioon kuupäevad rikub

Kui kasutate Exchange'i halduskeskust (EAC) IMAP-migratsiooni konfigureerimiseks kohalikust serverist (Dovecot, Courier, Cyrus, UW-IMAP või mõni muu), loob Exchange Online ühenduse lähteallikaga IMAP kaudu, toob sõnumid välja ja süstib need sihtpostkastidesse oma sisemise transporditorustiku kaudu.

Just siin probleem tekib.

Iga e-kiri, mis läbib Exchange'i transporditorustiku, saab automaatselt ajatempliga Received: päise. See on SMTP- ja IMAP-serverite standardkäitumine juba aastakümneid: iga server, mis sõnumit puudutab, lisab sellele oma ajatempli. Probleem seisneb selles, et Outlook (eriti Outlook for Windows uuemates versioonides) kasutab kõige uuemat Received: päist kuvaviitena, kui muud metaandmed on mitmetähenduslikud.

Algne Date: päis (see, mis näitab, millal e-kiri tegelikult saadeti, vastavalt RFC 2822-le) on sõnumis endiselt olemas. Seda ei kustutatud. Aga Exchange'i süstimisel lisatud uus Received: päis "varjutab" selle.

Lisaks seatakse IMAP INTERNALDATE (metaandmed, mida IMAP-serverid kasutavad sõnumite sisemiseks dateerimiseks ja mis juhib sortimist enamikus e-posti klientides) süstimiskuupäevale, mitte e-kirja algsele kuupäevale. Exchange Online'il puudub igasugune natiivne viis lähtserveri INTERNALDATE säilitamiseks EAC kaudu pakettmigratsiooni käigus.

EAC vs. kolmandate osapoolte tööriistad: oluline erinevus

Tuleb eristada kahte olukorda. Tööriistadega nagu BitTitan MigrationWiz või CloudM Migrate esineb probleem samuti, kuid neil tööriistadel on mõnikord konfiguratsioonivõimalusi (pooleldi dokumenteeritud, sageli täpsema seadistuse all peidetud), mis püüavad teatud kuupäevametaandmeid säilitada.

EAC kaudu natiivne migratsioon ei paku sellist võimalust. Microsoft ei paljasta ühtegi parameetrit INTERNALDATE säilitamise kontrollimiseks pakettmigratsiooni torustikus. See on must kast: konfigureerite batchit, käivitate selle, Exchange teeb sisemiselt, mida tahab. Ja mida ta teeb, süstemaatiliselt, on dateerida sõnumid nende süstimise kuupäevaga.

(Muide, kui olete kunagi proovinud lugeda EAC kaudu migreeritud e-kirja toorseid päiseid, teate, et Exchange'i lisatud Received: väli on kohe äratuntav: see sisaldab viiteid Microsofti sisemistele serveritele nagu *.protection.outlook.com või *.prod.exchangelabs.com, täpselt migratsiooniakna ajatempliga.)

Miks batchit uuesti luua ei aita

Paljude IT-administraatorite esimene instinktiivne reaktsioon on: "Kui kustutan migreeritud postkastid ja käivitan batchit nullist, äkki on seekord kuupäevad õiged."

Arusaadav mõte. Kuid see ei tööta.

Probleem ei ole batchit konfiguratsioonis. See pole parameeter, mida unustati märkida. See peitub Exchange'i transporditorustiku arhitektuuris, mis on igal migratsioonil identne. Batchit uuesti käivitades saate täpselt sama tulemuse: samad Received: päised uue migratsioonikuupäevaga ja samad valed INTERNALDATE väärtused. Olete aega raisanud ja kasutajad häiriti teist korda ilma põhjuseta.

Mõned administraatorid proovivad ka Outlooki sortimisseadeid muuta ("sorteeri saatmiskuupäeva järgi" mitte "vastuvõtmiskuupäeva järgi"). Sortimine saatmiskuupäeva järgi ei ole lahendus. See on plaaster. Date: päis ja INTERNALDATE jäävad valeks klientidele, kes seda seadistust ei paku, samuti OWA jaoks, Outlook Mobile jaoks ja kõigi kolmandate osapoolte rakenduste jaoks, mis kasutavad postkasti IMAP või EWS kaudu.

Mis tegelikult päistes toimub

Siin on lihtsustatud näide sellest, mida e-kiri sisaldab pärast EAC kaudu migratsiooni. Algne päis:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@vanadomeen.ee
Subject: Q1 2019 aruanne

Pärast migratsiooni saab sõnum ahela algusesse midagi sellist:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook näeb seda Received: päist esimesena (see lisatakse päiseploki ülaossa), tõlgendab seda sõnumi viimase töötlemise kuupäevana ja kuvab selle vastuvõtmiskuupäevana. 2019. aasta algne Date: päis on endiselt seal, puutumata, mõned read allpool. Kuid Outlook ei kasuta seda sõnumite loendis kuvamiseks.

Täpsemalt: käitumine varieerub veidi Outlooki versiooniti. 2021. järgsed versioonid (ja eriti uus Outlook for Windows, mis võeti kasutusele 2023. aasta lõpus) on selle probleemi suhtes eriti tundlikud, kuna need tuginevad rohkem Exchange Graph metaandmetele kui töötlemata Date: päisele. See tähendab, et migratsioonid, mis Outlook 2016-ga nähtavaid probleeme ei tekitanud, võivad uue Outlookiga nüüd probleeme põhjustada.

Keda see tegelikult mõjutab

Seda tüüpi migratsioonis kõige levinumad IMAP-lähteserverid on Dovecot (väga levinud Linux/cPanel keskkondades) ja Courier. Mõlemad pakuvad IMAP kaudu INTERNALDATE väärtusi, mida EAC ei säilita. Kui migreerisite Exchange On-Premises'ist Exchange Online'i (hübriid- või cutover-migratsioon), on käitumine erinev, kuna Microsoft kasutab sisemist transpordiprotokolli (MAPI/EWS), mis metaandmeid paremini säilitab. Probleem on spetsiifiline EAC kaudu tehtavale üldisele IMAP-migratsioonile.

Kõige enam kannatavad kasutajad, kellel on pika ajalooga postkastid (5 aastat ja rohkem) ning suur sõnumite maht. Kasutaja, kellel on 300 e-kirja, tuleb sellega kiiresti toime. Müügidirektor, kellel on 12 000 kuupäeva järgi sorteeritud e-kirja, millest ta iga päev klientide kirjavahetuse leidmiseks sõltub - tema on halvatud.

Miks omatehtud skript on siin halb mõte

Mõned IT-administraatorid, kes tehnilist probleemi mõistavad, on kiusatuses kirjutada PowerShelli või Pythoni skripti päiste käsitsi parandamiseks. Põhikontseptsioon võib pärast mehhanismi tuvastamist lihtsana näida. Kuid tegelikkus tootmiskeskkonnas on hoopis teine lugu.

Esiteks, äärmuslikud juhtumid. S/MIME allkirjastatud e-kirjadel ja PGP-krüpteeritud sõnumitel on struktuur, mis ei talu päiste muutmist allkirja kehtetuks muutmata. Multipart/alternative sõnumid valesti moodustatud MIME piiridega (vanemate Courier-serverite puhul sagedased) võivad skriptiga rikkuda, kui skript muudab sõnumit ilma struktuuri korrektselt taastamata. RFC 2047 järgi kodeeritud mitte-ASCII päised (saatjate nimed rõhumärkide või jaapanikeelsete tähtedega) on klassikaline veaallikas.

Teiseks, maht. Skript, mis töötab 50 testimis-e-kirjaga arenduskeskkonnas, ei käsitle Exchange Online'i API kiiruspiiranguid tootmiskeskkonnas. Viga 429 Too Many Requests kell 2 öösel 8000 sõnumi batchis, ilma taastumismehhanismita, tähendab valget ööd ja potentsiaalselt dubleeritud või kadunud sõnumeid.

Ja mis peamine: kuidas kontrollida, et iga parandatud e-kiri on terviklik? Et ühtki manust pole kärbitud, ühtki vestluslõime pole katkenud, sildid ja kaustad on säilinud? Ilma individuaalse valideerimismehhanismita loodate lihtsalt, et kõik läks hästi.

Kuupäevade parandamine pärast migratsiooni on probleem, mis näib 50-realise skripti moodi, kuid tootmiskeskkonnas usaldusväärseks muutmiseks vajab tuhandeid.

Mida Redate.io teisiti teeb

Redate.io loob ühenduse Exchange Online'iga Microsoft 365 API-de kaudu (Azure Active Directory, tenanditaseme delegeeritud õigused) ja skannib asjaomased postkastid, et tuvastada e-kirjad, mille kuupäevametaandmed migratsioon on rikkunud. See skannimise etapp on tasuta ja annab täpse ülevaate probleemi ulatusest: mõjutatud sõnumite arv, asjaomased postkastid, rikutud kuupäevade vahemik.

Seejärel töötleb Redate.io patenteeritud parandusmotor iga e-kirja individuaalselt läbi mitmeastmelise analüüsitorustiku, mis hõlmab mustrite sobitamist teadaolevate migratsioonivahenditega (sealhulgas Exchange Online'i transporditorustik), RFC-vastavuse valideerimist ning sõnumi struktuurse terviklikkuse kontrollimist enne ja pärast parandamist. S/MIME allkirjastatud e-kirjad, keerulised MIME-struktuurid, mittestandardsed kodeeringud - kõiki neid käsitletakse spetsiifiliste töötlusmeetoditega.

Iga parandatud sõnum kontrollitakse eraldi. Originaalid säilitatakse nähtavas varunduskaustas 30 päeva jooksul. Kui mõne konkreetse sõnumiga midagi ei klapi, seda ei muudeta: Redate.io annab anomaliast teada selle asemel, et riskida andmete rikkumisega.

Hinnakujundus põhineb mahul, ühekordsete maksena postkasti kohta. Tellimuselepingut ei ole, korduvkulusid ei ole. Parandate probleemi korra - ja see on kõik.

Exchange Online'i migratsioonide puhul toetab Redate.io ühendust Azure AD rakenduseõiguste kaudu (ilma vajaduseta luua iga postkasti jaoks eraldi mandaate), mis muudab suurte postkastiparkide käsitlemise IT-administraatori või MSP jaoks oluliselt lihtsamaks.

Kui haldate mitut klienti, kes on seda tüüpi migratsiooni läbi teinud, vaadake ka täielikku juhendit kuupäevade parandamiseks pärast Microsoft 365 migratsiooni, et saada ülevaade kõigist kaetud stsenaariumidest.

E-kirjad on olemas, algsed kuupäevad samuti. Käivitage tasuta skannimine Redate.io-s, et näha täpselt, kui palju sõnumeid teie Exchange Online'i postkastides mõjutatud on, enne kui otsustate, mida teha.