Outlook: datum primitka IMAP migracije vs datum slanja

Simptom koji svi poznaju

Upravo ste završili IMAP migraciju na Microsoft 365 ili Google Workspace. Ponedjeljak ujutro, ticketi se nižu: "Svi moji emailovi imaju isti datum", "Moja povijest je uništena", "Ne mogu ništa pronaći u sandučiću". Otvarate Outlook i zaista, tisuće emailova prikazuju datum prošlog vikenda. Ne datum kada su poslani. Datum kada se odvijala migracija.

To nije Outlookov bug. To je izravna posljedica načina na koji IMAP protokol i alati za migraciju funkcioniraju. Ali da bismo razumjeli zašto, moramo otvoriti haubu.

Tri datuma u jednom emailu

Email je složeniji nego što izgleda. Zaglavlja, tijelo poruke, privitci... i nekoliko različitih vremenskih oznaka koje koegzistiraju. (Inače, ako ste ikad pokušali čitati sirova zaglavlja emaila, znate da to baš i nije čitanje za plažu.)

Zaglavlje Date: (RFC 2822)

To je datum koji je pošiljatelj upisao u poruku u trenutku slanja. Definirano RFC 2822 standardom, izgleda otprilike ovako:

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

Ovo zaglavlje je ugravirano u sadržaj poruke. Nikada se ne mijenja, osim ako netko izravno uređuje sirovi sadržaj poruke. To je "datum slanja" u pravom smislu riječi.

Zaglavlje Received: (dodaje se na svakom mrežnom skoku)

Svaki poslužitelj koji dodirne email u tranzitu dodaje zaglavlje Received: na vrh poruke, sa svojom vlastitom vremenskom oznakom. Email koji prođe kroz tri poslužitelja akumulira tri zaglavlja Received:. Najnovije je uvijek prvo. To izgleda otprilike ovako:

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: kada alat za migraciju poput BitTitan MigrationWiz, CloudM, imapsync ili GSMMO premjesti email s izvornog na odredišni poslužitelj, i on se ponaša kao "mrežni skok". Ubacuje novo zaglavlje Received: na sam vrh skupa, s datumom i vremenom migracije.

IMAP INTERNALDATE

To je treći datum, i taj je problematičan. INTERNALDATE je metapodatak pohranjen na strani IMAP poslužitelja, neovisan o sadržaju poruke. Predstavlja datum kada je email isporučen (ili umetnut) u sandučić. Kada alat za migraciju umetne email putem IMAP naredbe, on odlučuje koju vrijednost dodijeliti INTERNALDATE-u. I u mnogim slučajevima alati koriste datum trenutka migracije. Ne originalni datum.

Tu sve kreće po krivu.

Zašto Outlook prikazuje datum migracije

Outlook koristi INTERNALDATE za prikaz stupca "Primljeno". To je njegovo zadano ponašanje, i usklađeno je s IMAP specifikacijom: INTERNALDATE bi trebao predstavljati datum primitka u sandučić. U normalnom toku (pravi email koji stiže), INTERNALDATE je blizu datuma u zaglavlju Date:. Oboje su usklađeni.

Nakon neuspjele migracije, INTERNALDATE svih uvezenih emailova pokazuje na noć 14. na 15. lipnja 2024. (ili koji god datum migracije bio). Outlook čita tu vrijednost, prikazuje je u stupcu "Primljeno", i rezultat je katastrofalan: 45.000 emailova izgleda kao da su primljeni iste večeri.

Da budemo precizni, prvo zaglavlje Received: (najnovije u skupu) također utječe na prikaz u određenim konfiguracijama. Ali INTERNALDATE ostaje glavni čimbenik za stupac "Primljeno" u Outlooku u sinkroniziranom IMAP načinu.

Zaobilazno rješenje "Dodaj stupac Poslano" u Outlooku

Prva stvar koju većina IT administratora radi kada otkrije problem je traženje zaobilaznog rješenja na strani klijenta. I postoji jedno, zapravo.

U Outlooku je moguće izmijeniti prikaz stupaca mape kako bi se zamijenio (ili dopunio) stupac "Primljeno" stupcem "Datum" ili "Poslano". Stupac "Datum" izravno čita zaglavlje Date: poruke, ne INTERNALDATE. Budući da zaglavlje Date: nije dirala migracija, originalni datumi se ponovo pojavljuju.

Kako to napraviti u Outlooku (desktop, verzija Microsoft 365): desni klik na zaglavlje stupca u popisu poruka, "Postavke prikaza", zatim izmijenite stupce da uklonite "Primljeno" i dodate "Datum". Može se primijeniti putem GPO-a za masovnu implementaciju.

U teoriji, to rješava vizualni problem. U praksi, to je flaster na arteriji.

Konkretna ograničenja tog zaobilaznog rješenja

Mobilni i web klijenti

Outlook na iOS-u, Androidu i Outlook Web App (OWA) nemaju iste mogućnosti prilagodbe. Izmjena prikaza koju ste primijenili na Windows računalima ne propagira se dalje. Vaši korisnici koji čitaju emailove na mobitelu i dalje vide datum migracije. A u tvrtki srednje veličine, to je vjerojatno polovica korisnika.

Pretraživanje

Outlookovo pretraživanje koristi Windows Search indeks (ili Exchange/Microsoft 365 indeks na strani poslužitelja). Taj indeks je izgrađen na temelju INTERNALDATE-a, ne zaglavlja Date:. Ako korisnik traži "emailovi iz siječnja 2022.", pretraživanje vraća emailove čiji je INTERNALDATE u siječnju 2022. Ne one čije je zaglavlje Date: iz siječnja 2022. Posljedica: stari emailovi više se ne prikazuju u filtrima po datumu. Promjena stupca prikaza tu ništa ne mijenja.

Pravila poruka

Outlookova pravila ("ako je email primljen prije...", "ako je email primljen nakon...") također koriste INTERNALDATE. Pravilo za sortiranje ili arhiviranje temeljeno na rasponima datuma neće ispravno funkcionirati nakon migracije ako INTERNALDATE nije ispravljen.

Usklađenost i eDiscovery

Ovo je možda najozbiljnija točka. Alati za usklađenost, pravno arhiviranje i eDiscovery (Microsoft Purview, primjerice) koriste INTERNALDATE kao referentni datum za pravne upite. Ako Vaša tvrtka podliježe obvezama čuvanja podataka ili mora odgovarati na zahtjeve za otkrivanje podataka, oštećeni INTERNALDATE-ovi mogu uzrokovati stvarne pravne probleme. Revizija koja traži "sve emailove između tog i tog datuma" neće vratiti ispravne rezultate.

Alati trećih strana

CRM sustavi, alati za ticketing, archivatori... sve što se spaja na Vaš mail poslužitelj putem IMAP-a ili Microsoft 365/Google Workspace API-ja čita INTERNALDATE. Promjena Outlookovog prikaza ništa ne ispravlja za te sustave.

Jedino pravo rješenje: ispravak na razini poslužitelja

Sortiranje po datumu slanja u Outlooku nije rješenje. To je flaster. Pravi ispravak mora se provesti na razini metapodataka poslužitelja, ne na razini prikaza klijenta.

Konkretno, to znači ispraviti INTERNALDATE svakog emaila tako da odgovara originalnom datumu iz zaglavlja Date:. Originalno zaglavlje Date: uvijek je prisutno u poruci (migracija ga nije obrisala), što ispravak čini mogućim. Tu se nalazi stvarna informacija o datumu.

Na Google Workspaceu, Gmail API izlaže parametar internalDate koji omogućuje izravno djelovanje na taj metapodatak. Na Microsoft 365-u, mehanizam je drugačiji, ali očekivani rezultat je isti. Na standardnom IMAP poslužitelju, standard predviđa da se datum može specificirati pri umetanju poruke.

U praksi, provesti tu operaciju na desecima tisuća emailova u produkciji, bez gubitka podataka, bez duplikata, bez kvarenja niti razgovora ili oznaka, uz obradu rubnih slučajeva (S/MIME potpisane poruke, složene MIME strukture, ne-ASCII kodiranja prema RFC 2047, veliki privitci)... to je sasvim druga stvar. Skripta koja radi na 50 testnih emailova neće izdržati na sandučiću od 40.000 poruka. Upravljanje greškama 429 (prekoračena API kvota), mrežni timeouti u 2 ujutro, poruke čija je MIME struktura već djelomično oštećena nakon migracije... sve to zahtijeva ozbiljno inženjerstvo.

Upravo to radi Redate.io. Vlasnički motor za ispravak analizira lanac zaglavlja svakog emaila, identificira pouzdan originalni datum i primjenjuje ciljani ispravak metapodataka bez diranja sadržaja poruke. Svaki ispravljen email se pojedinačno verificira. Originali se čuvaju u sigurnosnoj kopiji 30 dana, što u svakom trenutku omogućuje povratak na prethodno stanje. Nešto što kućna skripta nikad ne nudi.

Identifikacija odgovornog alata za migraciju

Problem se manifestira na isti način bez obzira na porijeklo migracije, ali detalji variraju ovisno o korištenom alatu. BitTitan MigrationWiz, CloudM, imapsync i GSMMO imaju svaki svoj potpis u zaglavljima Received: koja ubacuju. Analitički pipeline Redate.io-a održava bazu podudaranja s potpisima stotina poznatih alata za migraciju kako bi razlikovao migracijska zaglavlja od ostatka legitimnog tranzitnog lanca.

Ako ne znate koji je alat korišten za Vašu migraciju (to se dogodi, posebno kada preuzimate infrastrukturu nakon drugog MSP-a), besplatno skeniranje Redate.io-a identificira zahvaćene sandučiće i daje procjenu volumena za ispravak prije ikakve obveze.

Za specifične kontekste, dostupni su detaljni vodiči: ispravak datuma imapsync u Outlooku, ispravak datuma BitTitan u Outlooku, ili ispravak datuma CloudM u Outlooku.

Što učiniti sada

Ako čitate ovaj članak nakon migracije, dobra vijest je da je originalno zaglavlje Date: netaknuto u svakom Vašem emailu. Stvarne informacije o datumu su tu, prisutne u svakoj poruci. Problem je u metapodacima, ne u sadržaju. A metapodaci se mogu ispraviti.

Možete pogledati i članak IMAP INTERNALDATE: zašto se datumi kvare za dublji uvid u mehaniku problema, ili kompletan vodič o krivim datumima u Outlooku nakon migracije ako želite pregled svih mogućih scenarija.

Spremni ispraviti datume Vaših sandučića? Pokrenite besplatno skeniranje na Redate.io kako biste identificirali zahvaćene emailove i procijenili volumen prije bilo kakvog ispravka.