Outlook: IMAP saņemšanas datums vs nosūtīšanas datums

Simptoms, ko pazīst visi

Jūs tikko pabeidzāt IMAP migrāciju uz Microsoft 365 vai Google Workspace. Pirmdien no rīta sākas pieteikumi: "Visiem e-pastiem ir vienāds datums", "Mans vēsturiskais arhīvs ir salauzts", "Nevaru neko atrast pastkastē". Atverat Outlook un patiešām redzat, ka tūkstošiem e-pastu rāda pagājušās nedēļas nogales datumu. Nevis datumu, kad tie tika nosūtīti. Datumu, kad notika migrācija.

Tas nav Outlook kļūda. Tā ir tieša IMAP protokola un migrācijas rīku darbības sekas. Bet lai saprastu kāpēc, jāatver motora vāks.

Trīs datumi vienā e-pastā

E-pasts ir sarežģītāks, nekā šķiet. Galvenes, ziņojuma saturs, pielikumi... un vairāki atsevišķi laika zīmogi, kas pastāv vienlaikus. (Starp citu, ja esat kādreiz mēģinājis lasīt e-pasta neapstrādātās galvenes, zināt, ka tas nav tieši pludmales lasāmviela.)

Galvene Date: (RFC 2822)

Tas ir datums, ko sūtītājs ievietoja ziņojumā nosūtīšanas brīdī. Definēts ar RFC 2822, tas izskatās šādi:

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

Šī galvene ir iegravēta ziņojuma struktūrā. Tā nekad nemainās, ja vien kāds nepārveido ziņojuma neapstrādāto saturu. Tā ir "nosūtīšanas datums" šaurā nozīmē.

Galvene Received: (pievienota katrā tīkla pārsūtīšanā)

Katrs serveris, kas apstrādā e-pastu tranzītā, pievieno Received: galveni ziņojuma sākumā ar savu datumu. E-pasts, kas iziet cauri trim serveriem, uzkrāj trīs Received: galvenes. Jaunākā vienmēr ir pirmā. Tas izskatās aptuveni šādi:

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)

Rezultāts: kad migrācijas rīks, piemēram, BitTitan MigrationWiz, CloudM, imapsync vai GSMMO, pārvieto e-pastu no avota servera uz galamērķa serveri, arī tas uzvedas kā "tīkla pārsūtīšana". Tas injicē jaunu Received: galveni steka augšpusē ar migrācijas datumu un laiku.

IMAP INTERNALDATE

Tā ir trešā datuma vērtība, un tieši tā rada problēmas. INTERNALDATE ir metadatu lauks, kas tiek glabāts IMAP servera pusē, neatkarīgi no ziņojuma satura. Tas apzīmē datumu, kurā e-pasts tika piegādāts (vai ievietots) pastkastē. Kad migrācijas rīks ievieto e-pastu, tas pats izvēlas, kādu vērtību piešķirt INTERNALDATE. Un daudzos gadījumos rīki izmanto migrācijas brīža datumu. Nevis oriģinālo datumu.

Te viss saiet greizi.

Kāpēc Outlook rāda migrācijas datumu

Outlook izmanto INTERNALDATE, lai attēlotu kolonnu "Saņemts". Tā ir noklusējuma uzvedība, kas atbilst IMAP specifikācijai: INTERNALDATE ir paredzēta kā saņemšanas datuma pārstāvis pastkastē. Normālā e-pasta plūsmā (īsts e-pasts, kas ierodas) INTERNALDATE ir tuva Date: galvenes vērtībai. Abas ir saskaņotas.

Pēc neveiksmīgas migrācijas visu importēto e-pastu INTERNALDATE rāda uz 2024. gada 14.-15. jūnija nakti (vai kāds cits migrācijas datums). Outlook nolasa šo vērtību, attēlo to kolonnā "Saņemts", un rezultāts ir katastrofāls: 45 000 e-pastu šķiet saņemti vienā vakarā.

Precīzāk sakot, pirmā Received: galvene (jaunākā stekā) arī ietekmē attēlojumu dažās konfigurācijās. Taču INTERNALDATE paliek galvenais noteicošais faktors kolonnas "Saņemts" attēlojumam Outlook sinhronizētajā IMAP režīmā.

Risinājums "Pievienot kolonnu Nosūtīts" programmā Outlook

Pirmā lieta, ko vairums IT administratoru dara, atklājot problēmu, ir meklēt apkārtceļu klienta pusē. Un tāds tiešām pastāv.

Outlook ļauj mainīt mapes kolonnu attēlojumu, lai aizstātu (vai papildinātu) kolonnu "Saņemts" ar kolonnu "Datums" vai "Nosūtīts". Kolonna "Datums" nolasa tieši ziņojuma Date: galveni, nevis INTERNALDATE. Tā kā Date: galvene migrācijas laikā netika mainīta, oriģinālie datumi atkal parādās.

Lai to izdarītu Outlook (darbvirsmas versijā, Microsoft 365): ar peles labo pogu noklikšķiniet uz kolonnas galvenes ziņojumu sarakstā, izvēlieties "Skata iestatījumi", pēc tam mainiet kolonnas, noņemot "Saņemts" un pievienojot "Datums". Masveida izvietošanai to var paveikt ar GPO.

Labi. Teorētiski tas atrisina vizuālo problēmu. Praksē tas ir plāksteris uz artērijas.

Konkrētie šī risinājuma ierobežojumi

Mobilās un tīmekļa klientu lietotnes

Outlook iOS, Android un Outlook Web App (OWA) nav tādu pašu pielāgošanas opciju. Skatījuma izmaiņas, ko esat izvietojis Windows datoros, netiek pārnēsātas. Lietotāji, kas lasa e-pastus savā tālrunī, joprojām redz migrācijas datumu. Vidēja lieluma uzņēmumā tas varētu būt puse no visiem lietotājiem.

Meklēšana

Outlook meklēšana izmanto Windows Search indeksu (vai Exchange/Microsoft 365 servera puses indeksu). Šis indekss tiek veidots no INTERNALDATE, nevis no Date: galvenes. Ja lietotājs meklē "e-pastus no 2022. gada janvāra", meklēšana atgriež e-pastus, kuru INTERNALDATE ir 2022. gada janvārī. Nevis tos, kuru Date: galvene ir janvārī. Rezultāts: vecie e-pasti vairs neparādās datumu filtros. Kolonnas attēlojuma maiņa to nemaina.

E-pasta kārtulas

Outlook kārtulas ("ja e-pasts tika saņemts pirms...", "ja e-pasts tika saņemts pēc...") arī izmanto INTERNALDATE. Kārtošanas vai arhivēšanas kārtula, kas balstīta uz datumu diapazoniem, pēc migrācijas nedarbosies pareizi, ja INTERNALDATE nav labota.

Atbilstība un eDiscovery

Tas droši vien ir nopietnākais punkts. Atbilstības nodrošināšanas, juridiskās arhivēšanas un eDiscovery rīki (piemēram, Microsoft Purview) izmanto INTERNALDATE kā datuma atsauci juridiskajiem pieprasījumiem. Ja jūsu uzņēmumam ir datu glabāšanas pienākumi vai tas atbild uz discovery pieprasījumiem saskaņā ar GDPR vai citiem noteikumiem, bojāti INTERNALDATE lauki var radīt reālas juridiskas problēmas. Revīzija, kas pieprasa "visus e-pastus noteiktā laika posmā", neatgriezīs pareizos rezultātus.

Trešo pušu rīki

CRM sistēmas, biļešu rīki, arhivatori... viss, kas pieslēdzas pasta serverim caur IMAP vai Microsoft 365/Google Workspace API, nolasa INTERNALDATE. Outlook skatījuma maiņa neko neizlabo šīm sistēmām.

Vienīgais īstais risinājums: labošana servera līmenī

Kārtošana pēc nosūtīšanas datuma Outlook nav risinājums. Tas ir plāksteris. Īstai labošanai jānotiek metadatu līmenī serverī, nevis klienta skatījumā.

Konkrēti tas nozīmē katra e-pasta INTERNALDATE labošanu, lai tā atbilstu oriģinālās Date: galvenes datumam. Oriģinālā Date: galvene joprojām ir klāt ziņojumā (migrācija to nav dzēsusi), kas padara labošanu iespējamu. Tur atrodas reālā datuma informācija.

Google Workspace gadījumā Gmail API piedāvā parametru internalDate, kas ļauj tieši ietekmēt šos metadatus. Microsoft 365 gadījumā mehānisms ir atšķirīgs, bet sagaidāmais rezultāts ir tāds pats. Standarta IMAP serverim norma paredz, ka datumu var norādīt ziņojuma ievietošanas laikā.

Praksē šīs darbības veikšana desmitiem tūkstošu e-pastu ražošanas vidē, bez datu zudumiem, bez dublikātiem, nesalaužot diskusiju pavedienus vai birkas, apstrādājot robežgadījumus (ar S/MIME parakstīti ziņojumi, sarežģītas MIME struktūras, RFC 2047 ne-ASCII kodējumi, lieli pielikumi)... ir pavisam cits stāsts. Skripts, kas darbojas uz 50 testa e-pastiem, neizturēs 40 000 ziņojumu pastkastē. 429 kļūdu apstrāde (API kvotu pārsniegšana), tīkla taimautu vadība pulksten divos naktī, ziņojumi ar daļēji bojātu MIME struktūru pēc migrācijas... tas viss prasa nopietnu inženieriju.

Tieši to dara Redate.io. Patentētais labošanas dzinējs analizē katra e-pasta galvenu ķēdi, identificē uzticamo oriģinālo datumu un veic mērķtiecīgu metadatu labošanu, nepieskaroties ziņojuma saturam. Katrs labotais e-pasts tiek individuāli pārbaudīts. Oriģināļi tiek saglabāti rezerves kopiju mapē 30 dienas, kas nodrošina iespēju atgriešanās pie iepriekšējā stāvokļa jebkurā laikā. To mājas skripta risinājums nekad nepiedāvā.

Atbildīgā migrācijas rīka identificēšana

Problēma izpaužas vienādi neatkarīgi no migrācijas izcelsmes, taču detaļas atšķiras atkarībā no izmantotā rīka. BitTitan MigrationWiz, CloudM, imapsync un GSMMO katram ir sava paraksts injicētajās Received: galvenēs. Redate.io analīzes cauruļvads uztur atbilstības bāzi ar simtiem zināmo migrācijas rīku parakstu, lai atšķirtu migrācijas galveni no pārējās likumīgās tranzīta ķēdes.

Ja nezināt, kurš rīks tika izmantots jūsu migrācijai (tas notiek, īpaši ja pārskat sistēmas pēc cita MSP), Redate.io bezmaksas skenēšana identificē skartās pastkastes un sniedz labojamo apjomu novērtējumu pirms jebkādas saistīšanās.

Konkrētiem gadījumiem ir pieejami detalizēti ceļveži: imapsync datumu labošana Outlook, BitTitan datumu labošana Outlook vai CloudM datumu labošana Outlook.

Ko darīt tagad

Ja lasāt šo rakstu pēc migrācijas, labā ziņa ir tā, ka oriģinālā Date: galvene ir neskarta katrā jūsu e-pastā. Reālā datuma informācija tur ir, klāt katrā ziņojumā. Problēma ir metadatos, nevis saturā. Un metadatus var labot.

Varat arī apskatīt rakstu IMAP INTERNALDATE: kāpēc datumi sabojājas, lai dziļāk izprastu problēmas mehāniku, vai pilno ceļvedi par nepareiziem datumiem Outlook pēc migrācijas, ja vēlaties pārskatu par dažādiem gadījumiem.

Gatavi labot savu pastkastes datumus? Palaidiet bezmaksas skenēšanu Redate.io, lai identificētu skartus e-pastus un novērtētu apjomu pirms jebkādas labošanas.