Jaunais Outlook: nepareizi datumi pēc migrācijas

Divi Outlook, divas uzvedības ar vienādiem e-pastiem

Ja nesen migrējāt pastkastes uz Microsoft 365 un daži lietotāji sūdzas, ka visi viņu vecākie e-pasti rāda to pašu datumu (migrācijas datumu), iespējams, pamanījāt kaut ko dīvainu: klasiskā Outlook lietotāji dažreiz redz pareizo datumu lasīšanas rūtī, bet jaunā Outlook Windows versijas lietotāji sistemātiski redz migrācijas datumu. Viena un tā pati pastkaste. Tie paši e-pasti. Atšķirīgi rezultāti.

Tas nav kļūda tiešā nozīmē. Tā ir arhitektūras izvēle, kurai ir tiešas sekas uz to, kā datumi tiek parādīti pēc IMAP migrācijas. Lai saprastu, kas notiek, jāiedziļinās e-pasta galveņu un IMAP protokola detaļās, kas nav tieši viegla lasāmviela, taču ļauj saprast, kāpēc neviena klienta puses manipulācija nav pietiekama problēmas risināšanai.

IMAP INTERNALDATE: īstais vaininieks

Kad e-pasts tiek glabāts IMAP serverī, tam ir divu veidu datumi, kas pastāv līdzās un nepārklājas.

Pirmais ir galvene Date:, ko definē RFC 2822. Tas ir datums, kas ierakstīts pašā ziņojumā, ko sūtītājs norādīja, sūtot e-pastu. Tā ir daļa no ziņojuma pamatteksta un nekad nemainās neatkarīgi no tā, kādu ceļu e-pasts vēlāk pieveic.

Otrais ir INTERNALDATE, serverī pārvaldīts metadatu lauks, kas atrodas ārpus ziņojuma. Tas ir datums, kurā serveris reģistrēja ziņojumu. Paredzētas migrācijas laikā nopietni rīki saglabā sākotnējo INTERNALDATE. Taču nepareizi konfigurētas migrācijas laikā, vai ar noteiktiem rīkiem, kas neapstrādā šos metadatus pareizi, INTERNALDATE tiek atiestatīts uz migrācijas dienas datumu. Rezultāts: visi migrētie e-pasti servera acīs nes vienu un to pašu saņemšanas datumu.

(Starp citu, ja esat kādreiz lasījis imapsync vai MigrationWiz žurnālfailus, zināt, ka pastāv konkrētas opcijas, kas mēģina saglabāt INTERNALDATE. Šīs opcijas ne vienmēr darbojas, un daži mērķa serveri atsakās tās ievērot.)

Klasiskais Outlook: kā tas lasa datumus

Klasiskais Outlook, tas ir, lokāli instalētās COM versijas (Outlook 2016, 2019, 2021 un Microsoft 365 Apps darbvirsmas klients), izmanto nedaudz sarežģītāku mehānismu, lai noteiktu, kādu datumu parādīt ziņojumu sarakstā.

Nosūtīto e-pastu mapē tas balstās uz galveni Date:. Saņemtajiem e-pastiem tas prioritāri izmanto servera INTERNALDATE, taču noteiktos kontekstos (jo īpaši, kad ir iesaistīts OST kešatmiņa vai lasīšanas rūtī pirmo reizi tiek parādīts e-pasts) tas var arī lasīt Received: galveņu ķēdi, lai rekonstruētu aptuvenu sākotnējo datumu.

Tieši tāpēc novērojam šo nekonsekvento uzvedību: klasiskais Outlook dažreiz var parādīt pareizo datumu lasīšanas rūtī, jo tas lasa ziņojuma sākotnējo Date: galveni detalizētam priekšskatam, pat ja pats e-pastu saraksts izmanto bojāto INTERNALDATE. Taču uzmanību, tas nav uzticams un neko nelabo. Kārtošana joprojām ir bojāta, datumu meklēšana joprojām sniedz nepareizus rezultātus.

Jaunais Outlook: radikāli atšķirīga arhitektūra

Jaunais Outlook operētājsistēmai Windows, ko pakāpeniski izvietoja no 2023. gada beigām, vairs nav COM lietojumprogramma. Patiesībā tā ir progresīva tīmekļa lietotne (PWA), kas balstīta uz to pašu koda bāzi kā Outlook tīmeklī (OWA). Šai pārkārtošanai ir dziļas sekas.

Jaunais Outlook pilnībā uztic datumu attēlošanu Microsoft 365 API. Tas nelasa Received: galvenes, neiedziļinās galveņu ķēdē, meklējot sākotnējo datumu, un neveic nekādus mēģinājumus rekonstruēt datumu klienta pusē. Tas vienkārši parāda to, ko serveris tam atgriež: INTERNALDATE.

Rezultāts: ja INTERNALDATE migrācijas laikā tika bojāts, jaunajam Outlook nav nekādu šaubu. Tas parāda migrācijas datumu katram skartajam e-pastam, bez izņēmumiem, bez niansēm. Šī ir konsekventāka un paredzamāka uzvedība nekā klasiskajam Outlook, taču tā padara migrācijas problēmu nekavējoties redzamu un neiespējamu ignorēt.

Administrators, kurš migrē 300 pastkastes piektdienas vakarā, pirmdien no rīta atklās, ka visi jaunā Outlook lietotāji redz savas arhīva e-pastus ar pagājušās nedēļas nogales datumu. Atbalsta pieteikumi sāk pienākt ātri.

Kāpēc klienta puses risinājumi nedarbojas

Daudzi administratori izmēģina klienta puses risinājumus, pirms saprot, ka problēma ir servera datos. Lūk, klasiskie mēģinājumi un kāpēc tie neizdodas.

Kārtot pēc "Nosūtīšanas datuma" nevis "Saņemšanas datuma"

Kārtošana pēc nosūtīšanas datuma Outlook balstās uz ziņojuma galveni Date:, kas ir neskarta. Tātad jā, šī kārtošana var darboties. Bet tā ir ielāpa risinājums, nevis īsts labojums. Datumu meklēšana joprojām ir bojāta. Uz datumu balstīti noteikumi joprojām ir neizmantojami. Un pats galvenais, lietotājam manuāli jāpārkonfigurē katra mape, katra pastkaste. Ar 300 pastkastēm tas ir nereāli. Kārtošana pēc nosūtīšanas datuma nav risinājums, un gala lietotāji nesaprot, kāpēc viņiem liek mainīt ieradumus.

Iztīrīt Outlook kešatmiņu vai atjaunot profilu

Tas neietekmē servera puses INTERNALDATE. Pēc profila atjaunošanas Outlook atkārtoti sinhronizē e-pastus no servera un iegūst tieši tos pašus bojātos metadatus. Kešatmiņa nav problēma.

Izmantot OWA

OWA un jaunais Outlook izmanto vienu un to pašu datu bāzi. Ja INTERNALDATE Exchange Online serverī ir bojāts, OWA parāda tieši to pašu nepareizo datumu. Klienta maiņa nemaina datus.

Problēma ir serverī, katra ziņojuma metadatos. Neviena klienta puses darbība nevar labot servera pusē glabātos datus.

Received galveņu slazds: kāpēc tās visu sarežģī

Kad migrācijas rīks kopē e-pastu no viena servera uz otru caur IMAP, mērķa serveris automātiski pievieno Received: galveni ķēdes augšpusē ar ievietošanas datumu un laiku. Tā ir RFC atbilstošu SMTP un IMAP serveru normāla uzvedība.

Šīs galvenes uzkrājas pretējā e-pasta ceļojuma secībā. Jaunākā ir augšā. Daži e-pasta klienti lasa pirmo Received:, lai novērtētu saņemšanas datumu, kas dod migrācijas datumu nevis sākotnējo datumu.

Precizējums: šī uzvedība nav raksturīga tikai vienam rīkam. BitTitan MigrationWiz, CloudM, imapsync, GSMMO un pat manuāla IMAP kopēšana starp diviem Thunderbird klientiem visi rada šo rezultātu. Sākotnējā galvene Date: paliek neskarta ziņojumā. Tieši tas tehniski padara labošanu iespējamu. Taču INTERNALDATE ir atsevišķs servera pārvaldīts metadatu lauks, ko nevar labot, vienkārši manipulējot ar ziņojuma galvenēm klienta pusē.

Lai uzzinātu vairāk par šo mehānismu, raksts par IMAP INTERNALDATE un bojātiem datumiem izskaidro, kā šie metadati tiek pārvaldīti dažādos serveros.

Kuri migrācijas rīki rada šo problēmu Microsoft 365

Jautājums rodas bieži: vai visi migrācijas rīki izraisa šo problēmu?

Īsā atbilde: tas atkarīgs no konfigurācijas un mērķa platformas. Exchange Online / Microsoft 365 serveris ir īpaši stingrs attiecībā uz INTERNALDATE pārvaldību. Pat rīki, kas mēģina to saglabāt, dažreiz neizdodas, jo Graph API un EWS (Exchange Web Services) uzvedas atšķirīgi atkarībā no izmantotā ievietošanas ceļa.

BitTitan MigrationWiz ir viens no izplatītākajiem rīkiem migrācijām uz Microsoft 365, un tas ir arī viens no tiem, kuru datumu problēmas ir vislabāk dokumentētas. Īpašā lapa BitTitan datumu labošana Microsoft 365 aptver konkrētās konfigurācijas, kas jāpārbauda. CloudM un imapsync ir savas īpatnības, dokumentētas attiecīgi lapās CloudM datumu labošana Microsoft 365 un imapsync datumu labošana Microsoft 365.

Kas visiem šiem rīkiem kopīgs: sākotnējā galvene Date: izdzīvo migrāciju. Tā ir bāze, uz kuras labošana ir iespējama.

Kāpēc pašdarināts skripts šeit ir slikta ideja

Problēmas izprašana reizēm rada ilūziju, ka risinājums ir vienkāršs. Tas tā nav, ne ražošanas mērogā.

E-pastu metadatu modificēšana Exchange Online serverī nav triviāla lieta. Microsoft Graph API uzliek stingrus ātruma ierobežojumus (kļūda 429 Too Many Requests nakts pakešapstrādē rodas ātri). S/MIME parakstītu vai PGP šifrētu e-pastu apstrāde prasa īpašu uzmanību, lai neinvalidētu parakstus. Multipart struktūras ar lielām pielikumiem pievieno ierobežojumus tīkla pārtraukumiem. Un pats galvenais: kā pārbaudīt katru e-pastu atsevišķi, lai pārliecinātos, ka labošana ir bijusi veiksmīga, nemainot saturu vai pielikumus?

Skripts, kas labi darbojas uz 50 testa e-pastiem, nedarbosies vienādi uz pastkasti ar 40 000 ziņojumiem un 8 gadu vēsturi. Iespēja, ka robežgadījums kaut ko salauzīs, palielinās ar katru nākamo tūkstoti ziņojumu. Un bez atjaunošanas mehānisma kļūda pusceļā atstāj pastkasti nekonsekvētā stāvoklī.

Skatiet arī: e-pastu datumu labošana pēc Microsoft 365 migrācijas pilnīgam pieejamo opciju pārskatam.

Ko Redate.io dara konkrēti

Katrs lietotājs pierakstās ar savu Microsoft kontu, un Redate.io atver tikai šo pastkasti ar pierakstīšanās piešķirto piekļuvi, bez portāla un bez lietojumprogrammas reģistrēšanas. Bezmaksas skenē e-pastus ar nepareiziem datumiem, pēc tam uz identificētajiem ziņojumiem piemēro specializētu labošanas dzinēju. Daudzpakāpju analīzes pipelines veic atbilstības pārbaudi pret simtiem zināmu migrācijas rīku parakstu, RFC atbilstības validāciju un galveņu ķēdes analīzi, lai rekonstruētu pareizos datumu metadatus.

Katrs labotais e-pasts tiek pārbaudīts individuāli. Sākotnējie ziņojumi netiek dzēsti: tie paliek redzamā rezerves kopiju mapē, kamēr paši tos nedzēšat. Cenu modelis ir vienreizējs maksājums par pastkasti bez abonēšanas.

Jaunais Outlook pēc tam parāda pareizos datumus, jo servera dati ir laboti, nevis slēpti.

Vai jums ir skartas pastkastes jaunajā Outlook? Palaidiet bezmaksas skenēšanu Redate.io, lai precīzi noteiktu, cik e-pastu ir skarts, pirms izlemjat par turpmākajām darbībām.