Deljeni hosting ka Microsoft 365: problem sa datumima

Problem koji vam niko nije rekao

Upravo ste završili migraciju pošte sa OVH-a, Infomaniaka, Ionosa ili o2switcha na Microsoft 365. Čarobnjak za migraciju u EAC-u (Exchange Admin Center) radio je celu noć, sve je zeleno, sandučići su popunjeni. U ponedeljak ujutru, prvi tiket: "Svi moji stari emailovi imaju današnji datum." Zatim drugi. Zatim deset.

Ovo nije bag Microsoft 365-a. Nije ni slučajnost. To je mehanički rezultat IMAP migracije, a u slučaju deljenog hostinga, problem je često dvostruko gori nego kod klasičnih migracija. Evo zašto.

Kako IMAP upravlja datumima (i gde se sve kvari)

Svaki email koji se čuva na IMAP serveru ima dva odvojena tipa datiranja. S jedne strane, zaglavlje Date: (definisano RFC 2822 standardom), koje se nalazi u samom telu poruke i označava kada je poruka poslata ili primljena. S druge strane, INTERNALDATE, metapodatak na nivou servera koji beleži kada je ta poruka dostavljena u sandučić. Upravo tu vrednost klijenti kao što je Outlook koriste po podrazumevanoj vrednosti za sortiranje i prikaz emailova.

(Inače, ako ste ikada pokušali da čitate sirova zaglavlja emaila u EAC-u, znate da to nije baš ležerno štivo. Lako ima dvadeset do trideset linija zaglavlja pre nego što dođete do sadržaja.)

Kada alat za IMAP migraciju prenosi poruku iz jednog sandučića u drugi, mora da rekreira taj INTERNALDATE na odredištu. Neki alati to rade ispravno. Mnogi ne, ili to čine sa ograničenjima. Server primaoca, sa svoje strane, čuva ono što mu se dostavi: kada kopija nosi svoj originalni datum, Exchange Online taj datum čuva. Zato, kada su datumi pogrešni, treba posumnjati na alat, a ne na Microsoft 365.

Rezultat: svaki migriran email izgleda kao da je "primljen" na dan migracije. Nije bitno da li datira iz 2019. godine.

Scenario u dva koraka: zašto deljeni hosting pogoršava sve

Ovde situacija postaje zaista problematična za migracije sa deljenih hostova kao što su OVH, Infomaniak, Gandi, Ionos ili o2switch.

Ovi hostovi obično koriste deljene Postfix, Dovecot ili cPanel servere sa standardnim IMAP konfiguracijama. Mnoga mala i srednja preduzeća tamo su godinama gomilala emailove, ponekad još od 2010. ili 2012. Kada odluče da pređu na Microsoft 365, migracija se često odvija u dve faze.

Korak 1: prva greška u datumu (pre Microsoft 365)

U mnogim slučajevima, emailovi su već prošli kroz prvu migraciju. Kompanija je menjala deljene hostove jednom ili dva puta tokom godina: sa Gandija na OVH 2018, pa sa OVH-a na Infomaniak 2022, na primer. Svaki IMAP prenos mogao je da vrati originalni INTERNALDATE na dan prenosa (kad alat nije prosledio originalni datum), a neki alati takođe ostavljaju sopstvena zaglavlja migracije, datirana tim danom.

Kada emailovi stignu na Microsoft 365, već nose ožiljke. Originalno zaglavlje Date: je netaknuto (ono je deo tela poruke, niko ga ne dirà), ali metapodaci o datumu su već jednom poremećeni.

Korak 2: druga greška u datumu pri prelasku na Exchange Online

IMAP alat za migraciju u EAC-u, ili alat treće strane kao što je BitTitan MigrationWiz konfigurisan u IMAP modu, tada uvlači te emailove koji već imaju pogrešan datum. Ako taj alat takođe ne prosledi originalni datum svakog emaila, Exchange Online svrstava email pod dan prenosa, i to je "datum prijema" koji Outlook u krajnjem slučaju prikazuje.

Email poslat u martu 2017. može dakle nositi dva sloja pogrešnih datuma: zaglavlja migracije koja je ostavila selidba iz 2022, i datum prijema iz migracije na Microsoft 365 2024. Outlook prikazuje 2024. Korisnik vidi 2024. To je pogrešno na dva nivoa.

Da budemo precizni: nije uvek najnovije zaglavlje Received: ono koje se koristi. Outlook određuje datum prikaza na osnovu kombinacije INTERNALDATE-a Exchange Online sandučića i prisutnih zaglavlja. Ali kad god alat za migraciju ne prosledi originalne datume, prelazak na Exchange Online dodaje novi sloj pogrešnih datuma povrh starog.

Alati za migraciju i hostovi: rizične kombinacije

Neke kombinacije se veoma često pojavljuju u migracijama sa deljenih hostova:

• OVH / Infomaniak / Ionos + IMAP alat iz EAC-a: Microsoftov izvorni alat je praktičan, ali je poznat po tome što ne čuva ispravno datume pri obimnim IMAP migracijama.
• cPanel (o2switch, LWS, itd.) + BitTitan MigrationWiz u IMAP modu: MigrationWiz u IMAP modu dodaje sopstvena migraciona zaglavlja. Rezultat je dokumentovan, između ostalog, na stranici Popravi datume BitTitan migracije u Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync je moćan alat, ali njegovo upravljanje INTERNALDATE-om zavisi od konfiguracije. Bez odgovarajuće opcije, datumi se ne čuvaju. Pogledajte i imapsync datumi nisu sačuvani.
• Svaka ručna migracija prevlačenjem u Outlooku: ako je neko kopirao cele foldere prevlačenjem između dva naloga podešena u Outlooku, INTERNALDATE svakog emaila je prepisan datumom kopiranja. Bez izuzetka.

Zajednički imenilac: sve ove metode rezultuju tim da emailovi u Exchange Online-u imaju datum prikaza u Outlooku koji više ne odgovara ničemu stvarnom.

Zašto je "sam to popravi" loša ideja na velikom obimu

Razumeti problem je jedna stvar. Ispraviti 8.000 emailova raspoređenih u 40 Exchange Online sandučića, na nalozima sa složenim strukturama foldera, S/MIME potpisanim emailovima, velikim prilozima i ugnežđenim nitima konverzacija, to je sasvim druga priča.

PowerShell skripta koja izgleda da radi na deset test emailova može tiho da zakaže na poruci broj 4237 zbog nepravilne MIME granice ili zaglavlja enkodiranog po RFC 2047 (onaj format =?UTF-8?B?...?= za ne-ASCII znakove u imenima pošiljalaca). Bez mehanizma pojedinačne provere, nećete znati. Imaćete samo izgubljen email.

Konkretni rizici DIY pristupa na ovoj vrsti migracije:

• Duple poruke ako logika umetanja zakaže na pola puta
• Nedostajući prilozi ako je multipart struktura loše rekonstruisana
• Pokidane niti konverzacija u Outlooku (razgovori se zasnivaju na zaglavljima References: i In-Reply-To: koja mogu biti izmenjena)
• Greške 429 (Too Many Requests) Microsoft Graph API-ja u 3 ujutru, koje prekidaju obradu bez rollbacka
• Nema jednostavnog načina da se provjeri da li je svih 8.000 ispravki ispravno primenjeno

A u specifičnom slučaju migracija sa deljenih hostova, postoji dodatna teškoća: emailovi nose više slojeva parazitskih zaglavlja Received:, ne samo jedno. Prosta skripta koja uklanja "poslednje Received:" nije dovoljna. Potrebno je analizirati kompletni lanac da bi se identifikovalo koje zaglavlje odgovara kojoj migraciji, i koje zapravo predstavlja originalni datum prijema.

Šta Redate.io radi drugačije

Redate.io se povezuje sa Microsoft 365 tako što se korisnik prijavljuje svojim Microsoft nalogom, a Redate.io tim putem dobija pristup samo tom sandučiću, bez portala i bez registracije aplikacije. Inicijalno skeniranje je besplatno: Redate.io identifikuje sve emailove čiji prikazani datum ne odgovara stvarnom datumu i daje preciznu procenu po sandučiću.

Ispravka se zasniva na vlasničkom mašinskom sistemu koji analizira kompletan lanac zaglavlja svake poruke, bez obzira na to koji je alat za migraciju korišćen, i ispravno rekonstruiše metapodatke datuma, čak i kada se više slojeva pogrešnih datuma preklapa. Svaki ispravljen email se proverava pojedinačno. Originali se čuvaju u vidljivoj fascikli u vašem poštanskom sandučetu, sve dok ih sami ne obrišete.

Za migracije sa deljenih hostova, višestepeni analitički pipeline Redate.io-a eksplicitno obrađuje scenarije dvostruko pogrešnih datuma: ne gleda samo na poslednje zaglavlje Received:, već prolazi kroz kompletnu istoriju kako bi pronašao stvarni datum prijema. Pogledajte i kako ispraviti datume posle migracije na Microsoft 365 opštim pristupom, kao i vodič o IMAP INTERNALDATE: zašto se datumi kvare za razumevanje mehanike u pozadini.

Pre migracije ili posle: dva trenutka za akciju

Dve situacije, dva pristupa.

Još niste migrirali. Dobra vest je da je moguće ograničiti štetu. Neki alati za migraciju (MigrationWiz u Exchange modu, CloudM sa ispravnim opcijama) bolje čuvaju datume od ostalih. Ali čak i u najboljem slučaju, migracija sa deljenog hostinga bez čiste istorije verovatno će ostaviti tragove. Planirajte prolaz kroz Redate.io posle migracije, pre nego što predate sandučiće korisnicima.

Već ste migrirali i tiketi stižu. Redate.io ispravlja postojeće sandučiće u Microsoft 365-u, bez obzira na to koliko je migracija stara. Skeniranje će Vam dati preciznu sliku stvarnog stanja svakog sandučića pre bilo kakve intervencije. Pogledajte i kontrolnu listu migracije emaila kako biste izbegli iste probleme u budućnosti.

Migrirali ste sa OVH-a, Infomaniaka, Ionosa ili o2switcha na Microsoft 365 i datumi su pogrešni? Napravite Redate.io nalog da besplatno skenirate sandučiće i tačno vidite obim problema pre nego što donesete bilo kakvu odluku.