Dijeljeni hosting prema M365: skriveni problem s datumima

Problem koji Vam nitko nije rekao

Upravo ste dovršili migraciju pošte s OVH-a, Infomaniaka, Ionosa ili o2switcha na Microsoft 365. Alat za migraciju u EAC-u (Exchange Admin Center) radio je cijelu noć, sve je zeleno, pretinci su popunjeni. U ponedjeljak ujutro, prvi zahtjev podrške: "Svi moji stari emailovi imaju današnji datum." Zatim drugi. Zatim deset.

To nije greška Microsoft 365. Nije ni slučajnost. To je mehanički rezultat IMAP migracije, i u slučaju dijeljenog hostinga, problem je često dvostruko ozbiljniji nego kod klasične migracije. Evo zašto.

Kako IMAP upravlja datumima (i gdje sve krene po krivu)

Svaki email pohranjen na IMAP poslužitelju ima dvije vrste datiranja. S jedne strane, zaglavlje Date: (definirano RFC 2822 standardom), prisutno u tijelu same poruke, koje pokazuje kada je poruka poslana ili primljena. S druge strane, INTERNALDATE, metapodatak na razini poslužitelja koji bilježi kada je ta poruka pohranjena u pretinac. Upravo tu vrijednost email klijenti poput Outlooka koriste kao zadanu za sortiranje i prikaz emailova.

(Inače, ako ste ikad pokušali čitati sirova zaglavlja emaila u EAC-u, znate da to baš i nije lektira za plažu. Ima lako dvadeset do trideset redaka zaglavlja prije nego što dođete do sadržaja.)

Kada alat za IMAP migraciju prenosi poruku iz jednog pretinca u drugi, mora ponovno stvoriti taj INTERNALDATE na odredištu. Neki alati to rade ispravno. Mnogi ne, ili to rade s ograničenjima. Poslužitelj primatelj, sa svoje strane, čuva ono što mu je predano: kada kopija nosi svoj izvorni datum, Exchange Online čuva taj datum. Zato kada datumi izađu pogrešni, uzrok treba tražiti u alatu, a ne u Microsoftu 365.

Rezultat: svaki migrirani email izgleda kao da je "primljen" na dan migracije. Nije važno da li datira iz 2019.

Scenarij u dva koraka: zašto dijeljeni hostinzi sve pogoršavaju

Tu situacija postaje zaista problematična za migracije s dijeljenih hostinga poput OVH-a, Infomaniaka, Gandija, Ionosa ili o2switcha.

Ti hostinzi uglavnom koriste dijeljene Postfix, Dovecot ili cPanel poslužitelje sa standardnim IMAP konfiguracijama. Mnoga mala i srednja poduzeća tamo su godinama skupljala emailove, ponekad od 2010. ili 2012. Kada odluče prijeći na Microsoft 365, migracija se često odvija u dva navrata.

Korak 1: prvo pogrešno datiranje (još prije Microsoft 365)

U mnogim slučajevima, emailovi su već prošli kroz prvu migraciju. Tvrtka je mijenjala dijeljeni hosting jednom ili dvaput kroz godine: s Gandija na OVH 2018., zatim s OVH-a na Infomaniak 2022., primjerice. Svaki IMAP prijenos mogao je vratiti originalni INTERNALDATE na dan prijenosa (ako alat nije prenio izvorni datum), a neki alati uz to ostavljaju i vlastita zaglavlja migracije, datirana tim danom.

Kada emailovi stignu na Microsoft 365, već nose ožiljke. Izvorno zaglavlje Date: je netaknuto (ono je dio tijela poruke, nitko ga ne dira), ali metapodaci datuma već su jednom bili narušeni.

Korak 2: drugo pogrešno datiranje pri prelasku na Exchange Online

IMAP alat za migraciju u EAC-u, ili alat treće strane poput BitTitan MigrationWiza u IMAP načinu rada, tada unosi te već pogrešno datirane e-poruke. Ako taj alat ne prenese izvorni datum svake e-poruke, Exchange Online tu e-poruku pohranjuje pod danom prijenosa, i to je "datum primitka" koji Outlook u konačnici prikazuje.

Email poslan u ožujku 2017. može tako nositi dva sloja pogrešnih datuma: zaglavlja migracije koja je ostavio prijenos iz 2022., i datum primitka iz migracije na Microsoft 365 iz 2024. Outlook prikazuje 2024. Korisnik vidi 2024. To je pogrešno na dvije razine.

Preciznosti radi: Outlook određuje prikazani datum kombinacijom INTERNALDATE-a koji je zabilježio Exchange Online i prisutnih zaglavlja. Ali kad god alat za migraciju ne prenese izvorne datume, prijelaz na Exchange Online dodaje novi sloj pogrešaka povrh starog.

Alati za migraciju i hostinzi: rizične kombinacije

Neke kombinacije se jako često pojavljuju u migracijama s dijeljenih hostinga:

• OVH / Infomaniak / Ionos + IMAP alat EAC-a: Microsoftov nativni alat je praktičan, ali poznat po tome da ne čuva ispravno datume pri voluminoznim IMAP migracijama.
• cPanel (o2switch, LWS i sl.) + BitTitan MigrationWiz u IMAP načinu: MigrationWiz u IMAP načinu dodaje vlastita zaglavlja migracije. Rezultat je dokumentiran, između ostalog, na stranici ispravak datuma migracije BitTitan u Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync je moćan alat, ali njegovo upravljanje INTERNALDATE-om ovisi o konfiguraciji. Bez odgovarajuće opcije, datumi se ne čuvaju. Pogledajte i imapsync: datumi nisu sačuvani.
• Svaka ručna migracija povlačenjem i ispuštanjem u Outlooku: ako je netko kopirao cijele mape metodom drag-and-drop između dva računa konfigurirana u Outlooku, INTERNALDATE svakog emaila je prepisan na datum kopiranja. Bez iznimke.

Zajednički nazivnik: sve te metode završavaju na Exchange Onlineu s emailovima čiji prikazani datum u Outlooku više ne odgovara ničemu stvarnom.

Zašto je "sam to ispraviti" loša ideja u većem opsegu

Razumjeti problem je jedno. Ispraviti 8000 emailova raspoređenih u 40 Exchange Online pretinaca, na računima sa složenim strukturama mapa, S/MIME potpisanim emailovima, velikim privitcima i ugniježđenim nitima rasprave, sasvim je drugo.

PowerShell skripta koja naizgled radi na deset testnih emailova može tiho zakazati na poruci broj 4237 zbog oštećene MIME granice ili zaglavlja kodiranog prema RFC 2047 (onaj format =?UTF-8?B?...?= za ne-ASCII znakove u imenima pošiljatelja). Bez mehanizma individualne provjere, to nećete znati. Jednostavno ćete imati izgubljen email.

Konkretni rizici DIY pristupa za ovu vrstu migracije:

• Duple poruke ako logika umetanja zakaže na pola puta
• Nedostajući privici ako se multipart struktura loše rekonstruira
• Pokvarene niti rasprave u Outlooku (razgovori se temelje na zaglavljima References: i In-Reply-To: koja mogu biti izmijenjena)
• Greške 429 (Too Many Requests) Microsoft Graph API-ja u 3 sata ujutro, koje prekidaju obradu bez mogućnosti povrata
• Nema jednostavnog načina provjere jesu li svih 8000 ispravaka ispravno primijenjeni

I u specifičnom slučaju migracija s dijeljenih hostinga, postoji dodatna teškoća: emailovi nose nekoliko slojeva parazitskih zaglavlja Received:, ne samo jedno. Jednostavna skripta koja uklanja "zadnje Received:" nije dovoljna. Potrebno je analizirati cijeli lanac kako bi se identificiralo koje zaglavlje odgovara kojoj migraciji, i koje zaista predstavlja originalni datum primitka.

Što Redate.io radi drukčije

Redate.io se povezuje s Microsoft 365 tako da se korisnik prijavi svojim Microsoft računom, a Redate.io otvara samo taj poštanski sandučić, s pristupom koji ta prijava dopušta. Početno skeniranje je besplatno: Redate.io identificira sve emailove čiji prikazani datum ne odgovara stvarnom datumu, i daje preciznu procjenu po pretincu.

Ispravak se temelji na vlasničkom motoru koji analizira cijeli lanac zaglavlja svake poruke, bez obzira na to koji je alat za migraciju korišten, i ispravno rekonstruira metapodatke datuma, čak i kada se više slojeva pogrešnih datuma preklapa. Svaka ispravljena e-poruka se individualno provjerava. Originali se čuvaju u vidljivoj mapi sigurnosne kopije unutar Vašeg poštanskog sandučića, sve dok ih sami ne obrišete.

Za migracije s dijeljenih hostinga, višestupanjski cjevovod za analizu Redate.io-a eksplicitno obrađuje scenarije dvostruko pogrešnih datuma: ne gleda samo zadnje zaglavlje Received:, nego prolazi kroz cijelu povijest kako bi pronašao stvarni datum primitka. Pogledajte i kako ispraviti datume nakon Microsoft 365 migracije općenito, te vodič o pokvarenim IMAP INTERNALDATE vrijednostima za razumijevanje temeljne mehanike.

Prije migracije ili poslije: dva trenutka za djelovanje

Dvije situacije, dva pristupa.

Još niste migrirali. Dobra vijest: moguće je ograničiti štetu. Neki alati za migraciju (MigrationWiz u Exchange načinu, CloudM s ispravnim opcijama) bolje čuvaju datume od drugih. Ali čak i u najboljem slučaju, migracija s dijeljenog hostinga bez uredne povijesti vjerojatno će ostaviti tragove. Planirajte prolaz kroz Redate.io nakon migracije, prije nego što predajte pretince korisnicima.

Već ste migrirali i zahtjevi za podršku stižu. Redate.io ispravlja postojeće pretince u Microsoft 365, bez obzira na starost migracije. Skeniranje Vam daje preciznu sliku stvarnog stanja svakog pretinca prije ikakve intervencije. Pogledajte i kontrolni popis za migraciju emailova kako biste izbjegli iste probleme u budućnosti.

Migrirate s OVH-a, Infomaniaka, Ionosa ili o2switcha na Microsoft 365 i datumi su pogrešni? Otvorite Redate.io račun i besplatno skenirajte svoje pretince kako biste točno vidjeli opseg štete prije nego što odlučite išta poduzeti.