Outlook: datum prejema IMAP vs datum pošiljanja

Simptom, ki ga vsi poznajo

Pravkar ste zaključili selitev IMAP v Microsoft 365 ali Google Workspace. V ponedeljek zjutraj se začnejo prijave: "Vsi moji e-poštni sporočili imajo isti datum", "Moja zgodovina je pokvarjena", "Nič ne najdem v svoji poštni skrinji". Odprete Outlook in res, tisoči e-poštnih sporočil prikazuje datum minulega vikenda. Ne datuma, ko so bila poslana. Datuma, ko je potekala selitev.

To ni hrošč v Outlooku. Je neposredna posledica delovanja protokola IMAP in orodij za selitev. Ampak da bi razumeli zakaj, moramo odpreti pokrov motorja.

Trije datumi v enem e-poštnem sporočilu

E-poštno sporočilo je bolj zapleteno, kot se zdi. Glava, telo sporočila, priponke... in več različnih časovnih žigov, ki sobivajo. (Mimogrede, če ste kdaj poskušali brati surove glave e-poštnih sporočil, veste, da to ni ravno poletno branje.)

Glava Date: (RFC 2822)

To je datum, ki ga je pošiljatelj vstavil v sporočilo ob pošiljanju. Definiran po RFC 2822, izgleda takole:

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

Ta glava je vgrajena v samo sporočilo. Nikoli se ne spremeni, razen če nekdo spremeni surovo vsebino sporočila. To je "datum pošiljanja" v strogem pomenu besede.

Glava Received: (dodana ob vsakem omrežnem preskoku)

Vsak strežnik, ki se dotakne e-poštnega sporočila med prenosom, doda glavo Received: na začetek sporočila s svojim datumom. Sporočilo, ki gre skozi tri strežnike, tako nabere tri glave Received:. Najnovejša je vedno na vrhu. Izgleda nekako tako:

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)

Rezultat: ko orodje za selitev, kot so BitTitan MigrationWiz, CloudM, imapsync ali GSMMO, premakne e-poštno sporočilo z izvornega na ciljni strežnik, se obnaša kot "omrežni preskok". Na vrh sklada vstavi novo glavo Received: z datumom in uro selitve.

IMAP INTERNALDATE

To je tretji datum in ravno ta povzroča težave. INTERNALDATE je metapodatek, shranjen na strani IMAP strežnika, neodvisen od vsebine sporočila. Predstavlja datum, ko je bilo e-poštno sporočilo dostavljeno (ali vstavljeno) v poštni predal. Ko orodje za selitev vstavi sporočilo prek IMAP protokola, samo odloči, katero vrednost dodeliti INTERNALDATE. In v številnih primerih orodja uporabijo datum trenutka selitve. Ne originalnega datuma.

Tu se vse zatakne.

Zakaj Outlook prikazuje datum selitve

Outlook uporablja INTERNALDATE za prikaz stolpca "Prejeto". To je njegovo privzeto obnašanje, skladno s specifikacijo IMAP: INTERNALDATE naj bi predstavljal datum prejema v poštni predal. V normalnem toku (pravo e-poštno sporočilo, ki pride), je INTERNALDATE blizu datuma v glavi Date:. Oba sta usklajena.

Po neuspeli selitvi INTERNALDATE vseh uvoženih e-poštnih sporočil kaže na noč med 14. in 15. junijem 2024 (ali kateri koli drug datum selitve). Outlook prebere to vrednost, jo prikaže v stolpcu "Prejeto" in rezultat je katastrofalen: 45.000 e-poštnih sporočil zdi, kot da so bila prejeta isto večer.

Natančneje povedano, prva glava Received: (najnovejša v skladu) vpliva tudi na prikaz v nekaterih konfiguracijah. Toda INTERNALDATE ostaja glavni dejavnik za stolpec "Prejeto" v Outlooku v sinhroniziranemu načinu IMAP.

Rešitev "Dodaj stolpec Poslano" v Outlooku

Prvo stvar, ki jo večina IT skrbnikov stori, ko odkrije težavo, je iskanje obhoda na strani odjemalca. In eden res obstaja.

V Outlooku je mogoče spremeniti prikaz stolpcev mape, da se stolpec "Prejeto" nadomesti (ali dopolni) s stolpcem "Datum" ali "Poslano". Stolpec "Datum" bere neposredno glavo Date: sporočila, ne INTERNALDATE. Ker glava Date: med selitvijo ni bila spremenjena, se originalni datumi znova pojavijo.

Kako to narediti v Outlooku (namizna različica, Microsoft 365): z desno tipko kliknite na glavo stolpca v seznamu sporočil, izberite "Nastavitve pogleda", nato spremenite stolpce tako, da odstranite "Prejeto" in dodate "Datum". To je izvedljivo prek GPO za množično uvajanje.

V teoriji to reši vizualni problem. V praksi je to obliž na arteriji.

Konkretne omejitve tega obhoda

Mobilni in spletni odjemalci

Outlook na iOS, Androidu in Outlook Web App (OWA) nimajo enakih možnosti prilagajanja. Sprememba pogleda, ki ste jo uvedli na Windows računalnikih, se ne prenese. Vaši uporabniki, ki berejo e-pošto na telefonu, še naprej vidijo datum selitve. In v povprečno velikem podjetju je to verjetno polovica uporabnikov.

Iskanje

Iskanje v Outlooku uporablja indeks Windows Search (ali indeks Exchange/Microsoft 365 na strani strežnika). Ta indeks je zgrajen na podlagi INTERNALDATE, ne glave Date:. Če uporabnik išče "e-poštna sporočila iz januarja 2022", iskanje vrne sporočila, katerih INTERNALDATE je iz januarja 2022. Ne tista, katerih glava Date: je iz januarja 2022. Rezultat: stara e-poštna sporočila se ne pojavijo v datumskih filtrih. Zamenjava stolpca za prikaz tega ne spremeni.

Pravila sporočanja

Pravila Outlooka ("če je bilo e-poštno sporočilo prejeto pred...", "če je bilo prejeto po...") prav tako uporabljajo INTERNALDATE. Pravilo za razvrščanje ali arhiviranje, ki temelji na datumskih razponih, po selitvi ne bo delovalo pravilno, če INTERNALDATE ni bil popravljen.

Skladnost in eDiscovery

To je morda najresnejša točka. Orodja za skladnost, pravno arhiviranje in eDiscovery (na primer Microsoft Purview) uporabljajo INTERNALDATE kot referenčni datum za pravne poizvedbe. Če je vaše podjetje zavezano zahtevam hrambe ali mora odgovarjati na zahteve za discovery, pokvarjeni INTERNALDATE lahko povzroči resne pravne težave. Revizija, ki zahteva "vsa e-poštna sporočila med tem in tem datumom", ne bo vrnila pravilnih rezultatov.

Orodja tretjih oseb

CRM sistemi, orodja za vodenje zahtevkov, arhivatorji... vse, kar se poveže z vašim poštnim strežnikom prek IMAP ali API-jev Microsoft 365/Google Workspace, bere INTERNALDATE. Zamenjava pogleda v Outlooku za te sisteme ne popravi ničesar.

Edina prava rešitev: popravek na ravni strežnika

Razvrščanje po datumu pošiljanja v Outlooku ni rešitev. Je obliž. Prava popravka mora biti izvedena na ravni metapodatkov strežnika, ne pogleda odjemalca.

Konkretno to pomeni popravek INTERNALDATE vsakega e-poštnega sporočila, da ustreza originalnemu datumu iz glave Date:. Originalna glava Date: je vedno prisotna v sporočilu (selitev je ni izbrisala), kar popravek sploh omogoča. Tam se nahaja informacija o dejanskem datumu.

V Google Workspace API Gmail izpostavlja parameter internalDate, ki omogoča neposredno ukrepanje na tem metapodatku. V Microsoft 365 je mehanizem drugačen, a pričakovani rezultat je enak. Na standardnem IMAP strežniku specifikacija predvideva, da je mogoče datum določiti ob vstavljanju sporočila.

V praksi izvesti to operacijo na desettisoče e-poštnih sporočil v produkciji, brez izgube podatkov, brez podvojitev, brez kvarjenja niti pogovorov ali oznak, z obvladovanjem mejnih primerov (sporočila, podpisana s S/MIME, zapletene strukture MIME, ne-ASCII kodiranja po RFC 2047, obsežne priponke)... to je povsem druga zadeva. Skript, ki deluje na 50 testnih sporočilih, ne bo zdržal pri poštnem predalu s 40.000 sporočili. Obvladovanje napak 429 (prekoračena kvota API), omrežnih prekinitev ob dveh zjutraj, sporočil, katerih struktura MIME je po selitvi že delno poškodovana... vse to zahteva resno inženirstvo.

Natančno to počne Redate.io. Lastniški mehanizem za popravek analizira verigo glav vsakega e-poštnega sporočila, identificira zanesljivi originalni datum in izvede ciljni popravek metapodatkov brez poseganja v vsebino sporočila. Vsako popravljeno sporočilo je preverjeno posamično. Originali so shranjeni v varnostni kopiji 30 dni, kar zagotavlja možnost razveljavitve kadarkoli. Kar domači skript nikoli ne ponudi.

Identifikacija odgovornega orodja za selitev

Težava se kaže enako ne glede na izvor selitve, a podrobnosti se razlikujejo glede na uporabljeno orodje. BitTitan MigrationWiz, CloudM, imapsync in GSMMO imajo vsak svojo signaturo v glavah Received:, ki jih vstavljajo. Analitični cevovod Redate.io vzdržuje bazo ujemanja s stotinami znanih signatur orodij za selitev, da loči glavo selitve od preostanka legitimne verige prenosa.

Če ne veste, katero orodje je bilo uporabljeno za vašo selitev (to se zgodi, zlasti ko prevzamete okolje po drugem MSP), brezplačno pregledovanje Redate.io identificira prizadete poštne predale in poda oceno obsega za popravek brez vsakršne obveznosti.

Za specifične primere so na voljo podrobni vodniki: popravek datumov imapsync v Outlooku, popravek datumov BitTitan v Outlooku ali popravek datumov CloudM v Outlooku.

Kaj storiti zdaj

Če berete ta članek po selitvi, je dobra novica ta, da je originalna glava Date: nedotaknjena v vsakem vašem e-poštnem sporočilu. Informacije o dejanskem datumu so tu, prisotne v vsakem sporočilu. Težava je v metapodatkih, ne v vsebini. Metapodatke pa je mogoče popraviti.

Prav tako si lahko ogledate članek IMAP INTERNALDATE: zakaj se datumi pokvarijo za globlje razumevanje mehanike problema, ali celotni vodnik o napačnih datumih v Outlooku po selitvi, če želite celovit pregled vseh scenarijev.

Pripravljeni popraviti datume v svojih poštnih predalih? Zaženite brezplačno pregledovanje na Redate.io in identificirajte prizadeta e-poštna sporočila ter ocenite obseg pred vsakim popravkom.