Outlook: IMAP migratsiooni vastuvõetud kuupäev vs saadetud kuupäev

Sümptom, mida kõik tunnevad

Olete lõpetanud IMAP-migratsiooni Microsoft 365-i või Google Workspace'i. Esmaspäeva hommikul hakkavad piletid laekuma: "Kõik minu meilid on sama kuupäevaga", "Minu ajalugu on katki", "Ma ei leia enam midagi oma postkastist". Avate Outlooki ja näete tõesti, et tuhanded meilid kuvavad eelmise nädalavahetuse kuupäeva. Mitte seda, millal need saadeti. Vaid seda, millal migratsioon toimus.

See ei ole Outlooki viga. See on IMAP-protokolli ja migratsioonitööriistade töömehhanismi otsene tagajärg. Aga et mõista, miks see juhtub, tuleb kapott avada.

Kolm kuupäeva ühes meilis

Meil on keerulisem, kui esmapilgul paistab. Päis, sõnumi sisu, manused... ja mitu erinevat ajatempli, mis kõik koos eksisteerivad. (Muide, kui olete kunagi proovinud lugeda meili toorseid päiseid, teate, et see pole just rannalugemist.)

Date: päis (RFC 2822)

See on kuupäev, mille saatja pani sõnumisse saatmise hetkel. RFC 2822 poolt määratletud, see näeb välja nii:

Date: Tue, 14 Mar 2023 09:42:17 +0100

See päis on sõnumi sisu sisse graveeritud. See ei muutu kunagi, välja arvatud juhul, kui keegi muudab sõnumi toorandmeid. See on "saadetud kuupäev" kitsas tähenduses.

Received: päis (lisatakse iga võrguhüppe juures)

Iga server, mis transiidi ajal meili käsitseb, lisab sõnumi päisesse Received: päise koos oma kuupäevaga. Meil, mis läbib kolm serverit, kogub kolm Received: päist. Uusim on alati esimene. Tulemus näeb välja umbes nii:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Tulemusena: kui migratsioonitööriist nagu BitTitan MigrationWiz, CloudM, imapsync või GSMMO teisaldab meili lähteserverist sihtserverisse, käitub ka see nagu "võrguhüpe". See sisestab virna ülaossa uue Received: päise koos migratsiooni kuupäeva ja kellaajaga.

IMAP INTERNALDATE

See on kolmas kuupäev ja just see tekitab probleemi. INTERNALDATE on IMAP-serveri poolel salvestatud metaandmed, mis on sõnumi sisust sõltumatu. See tähistab kuupäeva, millal meil postkasti tarniti (või sisestati). Kui migratsioonitööriist sisestab meili IMAP APPEND käsu kaudu, otsustab see ise, milline väärtus INTERNALDATE-le anda. Ja paljudel juhtudel kasutavad tööriistad migratsiooni hetke kuupäeva. Mitte originaalset kuupäeva.

Siin ongi kõige juured.

Miks Outlook kuvab migratsiooni kuupäeva

Outlook kasutab veeru "Vastuvõetud" kuvamiseks INTERNALDATE-i. See on selle vaikekäitumine ja on kooskõlas IMAP-spetsifikatsiooniga: INTERNALDATE on mõeldud tähistama postkasti kättesaamise kuupäeva. Normaalses voos (päris meil, mis saabub) on INTERNALDATE Date: päise kuupäevale lähedal. Mõlemad on kooskõlalised.

Ebaõnnestunud migratsiooni järel osutab kõigi imporditud meilide INTERNALDATE 14. juuni 2024 ööle (või mis iganes oli migratsiooni kuupäev). Outlook loeb selle väärtuse, kuvab selle veerus "Vastuvõetud" ja tulemus on katastroofiline: 45 000 meili näivad olevat saabunud samal õhtul.

Täpsustuseks: esimene Received: päis (virna kõige uuem) mõjutab kuvamist ka teatud konfiguratsioonides. Kuid INTERNALDATE on IMAP-sünkroonimisrežiimis Outlooki veeru "Vastuvõetud" peamine määraja.

"Lisa veerg Saadetud" lahendus Outlookis

Esimene asi, mida enamik IT-administraatoreid probleemi avastades teeb, on otsida kliendipoolset ajutist lahendust. Ja üks selline lahendus tõepoolest eksisteerib.

Outlookis saab muuta kausta veergude kuvamist, asendades (või täiendades) veeru "Vastuvõetud" veeruga "Kuupäev" või "Saadetud". Veerg "Kuupäev" loeb otse sõnumi Date: päist, mitte INTERNALDATE-i. Kuna migratsiooni ajal ei puudutata Date: päist, ilmuvad originaalsed kuupäevad uuesti.

Selle tegemiseks Outlookis (töölauaversioon, Microsoft 365): paremklik sõnumite loendi veerude päisel, "Vaatamisseaded", seejärel muutke veerge, et eemaldada "Vastuvõetud" ja lisada "Kuupäev". Massiliseks juurutamiseks on võimalik kasutada GPO-d.

Paberil tundub, et see lahendab visuaalse probleemi. Tegelikkuses on see plaaster arteril.

Selle lahenduse tegelikud piirangud

Mobiil- ja veebikliendid

Outlook iOS-il, Androidil ja Outlook Web App (OWA) ei paku samu kohandamisvõimalusi. Windowsi seadmetele juurutatud vaate muudatus ei kandu üle. Kasutajad, kes loevad meile telefonis, näevad endiselt migratsiooni kuupäeva. Ja keskmise suurusega ettevõttes on see tõenäoliselt pool kasutajatest.

Otsing

Outlooki otsing kasutab Windowsi otsinguindeksit (või Exchange/Microsoft 365 serveripoolset indeksit). See indeks on üles ehitatud INTERNALDATE põhjal, mitte Date: päise põhjal. Kui kasutaja otsib "jaanuari 2022 meile", tagastab otsing meilid, mille INTERNALDATE on jaanuaris 2022, mitte need, mille Date: päis on jaanuaris 2022. Tulemus: vanad meilid ei ilmu enam kuupäevafiltrites. Veeru kuvamise muutmine ei muuda seda kuidagi.

Meilireeglit

Outlooki reeglid ("kui meil saadi enne kuupäeva...", "kui meil saadi pärast kuupäeva...") kasutavad samuti INTERNALDATE-i. Kuupäevavahemikel põhinev sortimis- või arhiveerimisreegel ei tööta pärast migratsiooni õigesti, kui INTERNALDATE-i pole parandatud.

Vastavus ja e-tõendamine

See on ehk kõige tõsisem punkt. Vastavuse, õigusliku arhiveerimise ja e-tõendamise tööriistad (näiteks Microsoft Purview) kasutavad INTERNALDATE-i õiguslike päringute kuupäevaviitena. Kui teie ettevõte on kohustatud järgima andmesäilitamise nõudeid (GDPR, ISKE auditi nõuded) või peab vastama tõendamistaotlustele, võivad rikutud INTERNALDATE-id tekitada tõsiseid juriidilisi probleeme. Audit, mis nõuab "kõiki meile sellise ja sellise kuupäeva vahel", ei anna õigeid tulemusi.

Kolmanda osapoole tööriistad

CRM, piletisüsteemid, arhiveerijad... kõik, mis ühendub teie meiliserveriga IMAP-i või Microsoft 365/Google Workspace API kaudu, loeb INTERNALDATE-i. Outlooki vaate muutmine ei paranda midagi nende süsteemide jaoks.

Ainus tegelik lahendus: parandamine serveri tasemel

Saadetud kuupäeva järgi sortimine Outlookis ei ole lahendus. See on plaaster. Tegelik parandus peab toimuma serveri metaandmete tasemel, mitte kliendi vaates.

Konkreetselt tähendab see iga meili INTERNALDATE-i parandamist nii, et see vastaks Date: päise originaalsele kuupäevale. Originaalne Date: päis on alati sõnumis olemas (migratsioon ei kustutanud seda), mis teeb parandamise võimalikuks. Seal asub tegelik kuupäevateave.

Google Workspace'is pakub Gmail API internalDate parameetrit, mis võimaldab otse nendel metaandmetel toimida. Microsoft 365-s on mehhanism erinev, kuid oodatav tulemus on sama. Standardsel IMAP-serveril näeb standard ette, et kuupäeva saab sõnumi sisestamisel määrata.

Praktikas selle toimingu läbiviimine kümnete tuhandete tootmismeilide puhul, ilma andmekadudeta, ilma duplikaatideta, ilma aruteluniitide või siltide lõhkumiseta, hallatedes äärejuhte (S/MIME allkirjastatud sõnumid, keerukad MIME struktuurid, RFC 2047 mitte-ASCII kodeeringud, mahukad manused)... on hoopis teine asi. Skript, mis töötab 50 testmeiliga, ei pea vastu 40 000 sõnumiga postkastil. 429 vigade haldamine (API kvoot ületatud), võrgu aegumine kell 2 öösel, sõnumid, mille MIME struktuur on migratsiooni järel juba osaliselt rikutud... kõik see nõuab tõsist inseneritööd.

Täpselt seda teeb Redate.io. Patenteeritud parandusmootoril on mitmeastmeline analüüsisüsteem, mis hindab iga meili päiseahelat, tuvastab usaldusväärse originaalkuupäeva ja rakendab sihipärast metaandmete parandust sõnumi sisu puudutamata. Iga parandatud meil kontrollitakse eraldi. Originaalid säilitatakse varunduskaustas 30 päeva, mis tagab võimaliku tagasipöördumise igal ajal. Kodus kirjutatud skript seda kunagi ei paku.

Migratsiooni vastutava tööriista tuvastamine

Probleem avaldub ühtemoodi, olenemata migratsiooni päritolust, kuid üksikasjad erinevad vastavalt kasutatud tööriistale. BitTitan MigrationWiz, CloudM, imapsync ja GSMMO on igaühel oma signatuur Received: päistes, mida nad süstivad. Redate.io analüüsitorustik haldab sajandite tunnuste vastavust sadade teadaolevate migratsioonitööriistade signatuuride üle, et eristada migratsioonipäis ülejäänud seaduslikust transiidiahelast.

Kui te ei tea, millist tööriista kasutati teie migratsioonil (see juhtub, eriti kui võtate üle pargi teiselt MSP-lt), tuvastab Redate.io tasuta skannimine mõjutatud postkastid ja annab hinnangu parandatava mahu kohta enne igasugust kohustust.

Konkreetsete stsenaariumide jaoks on saadaval üksikasjalikud juhendid: imapsync kuupäevade parandamine Outlookis, BitTitani kuupäevade parandamine Outlookis ja CloudM kuupäevade parandamine Outlookis.

Mida nüüd teha

Kui loete seda artiklit pärast migratsiooni, on hea uudis see, et originaalne Date: päis on igas teie meilikuupäevateave sõnumis puutumatult olemas. Tegelik kuupäevateave on seal, igas sõnumis. Probleem on metaandmetes, mitte sisus. Ja metaandmeid saab parandada.

Rohkem probleemi mehaanika kohta leiate artiklist IMAP INTERNALDATE: miks kuupäevad katki lähevad või täielikust juhendist Outlooki valede kuupäevade kohta pärast migratsiooni, kui soovite ülevaadet kõikidest juhtudest.

Valmis oma postkastide kuupäevad parandama? Käivitage tasuta skannimine Redate.io-s, et tuvastada mõjutatud meilid ja hinnata mahtu enne parandamist.