Gostovanje v oblaku na Microsoft 365: skrita težava z datumi

Težava, ki vam je nihče ni omenil

Pravkar ste zaključili selitev e-pošte z OVH, Infomaniak, Ionos ali o2switch na Microsoft 365. Čarovnik za selitev v EAC (Exchange Admin Center) je tekel vso noč, vse je zeleno, nabiralniki so polni. V ponedeljek zjutraj prvi zahtevek: "Vsi moji stari e-poštni sporočili imajo današnji datum." Nato drugi. Nato deset.

To ni napaka Microsoft 365. Ni naključje. Je mehanski rezultat selitve IMAP, in pri gostovanju v skupnem okolju je težava pogosto dvakrat hujša kot pri navadni selitvi. Tukaj je razlog.

Kako IMAP upravlja datume (in kje gre narobe)

Vsako e-poštno sporočilo, shranjeno na strežniku IMAP, ima dve vrsti datumov. Na eni strani glava Date: (definirana po RFC 2822), ki je del samega sporočila in označuje, kdaj je bilo sporočilo poslano ali prejeto. Na drugi strani pa INTERNALDATE, metapodatek na ravni strežnika, ki pove, kdaj je bilo sporočilo dostavljeno v nabiralnik. Prav to vrednost e-poštni odjemalci, kot je Outlook, privzeto uporabljajo za razvrščanje in prikaz e-pošte.

(Mimogrede, če ste kdaj poskusili prebrati surove glave e-poštnega sporočila v EAC, veste, da to ni točno prijetno branje. Brez težav naštejete dvajset do trideset vrstic glav, preden pridete do vsebine.)

Ko orodje za selitev IMAP prenese sporočilo iz enega nabiralnika v drugega, mora na cilju znova ustvariti ta INTERNALDATE. Nekatera orodja to storijo pravilno. Mnoga tega ne storijo ali to storijo z omejitvami. In sprejemni strežniki imajo pri tem svojo besedo: Exchange Online obdrži datum, ki mu ga posreduje orodje za selitev: če kopija ohrani svoj prvotni datum, ga Exchange Online obdrži. Ko so datumi napačni, je torej treba pogledati orodje, ne Microsoft 365.

Rezultat: vsako selitveno sporočilo izgleda, kot da je bilo "prejeto" na dan selitve. Ni važno, da izvira iz leta 2019.

Scenarij v dveh korakih: zakaj skupno gostovanje vse poslabša

Tu postane situacija resnično problematična za selitve od ponudnikov skupnega gostovanja, kot so OVH, Infomaniak, Gandi, Ionos ali o2switch.

Ti ponudniki gostovanja navadno uporabljajo skupne strežnike Postfix, Dovecot ali cPanel s standardnimi konfiguracijami IMAP. Mnoga mala in srednje velika podjetja so tam kopičila e-pošto leta, včasih od 2010 ali 2012. Ko se odločijo za prehod na Microsoft 365, selitev pogosto poteka v dveh fazah.

1. korak: prva poškodba (še pred Microsoft 365)

V številnih primerih so e-poštna sporočila že preživela prvo selitev. Podjetje je zamenjalo ponudnika skupnega gostovanja enkrat ali dvakrat skozi leta: od Gandija na OVH leta 2018, nato z OVH na Infomaniak leta 2022, na primer. Vsak prenos IMAP je lahko ponastavil prvotni INTERNALDATE na dan prenosa, če orodje ni preneslo prvotnega datuma, nekatera orodja pa poleg tega dodajo tudi svoje glave selitve, datirane na ta dan.

Ko e-poštna sporočila pridejo na Microsoft 365, že nosijo brazgotine. Izvirna glava Date: je nedotaknjena (je del telesa sporočila, nihče se je ne dotakne), a metapodatki o datumu so bili že prvič napačni.

2. korak: druga poškodba pri prehodu na Exchange Online

Orodje za selitev IMAP v EAC ali orodje tretje strani, kot je BitTitan MigrationWiz v načinu IMAP, nato posrka te že napačno datirane e-pošte. Če tudi to orodje ne prenese prvotnega datuma vsakega sporočila, ga Exchange Online uvrsti na dan prenosa, in to je "datum prejema", ki ga nazadnje prikaže Outlook.

E-poštno sporočilo, poslano marca 2017, lahko torej nosi dve plasti napačnih datumov: glave selitve, ki jih je pustila selitev leta 2022, in datum prejema iz selitve na Microsoft 365 leta 2024. Outlook prikazuje 2024. Uporabnik vidi 2024. Napačno je na dveh ravneh.

Pravzaprav, da sem natančen: Outlook določi prikazani datum s kombinacijo INTERNALDATE, ki ga zapiše Exchange Online, in prisotnih glav. Kadar orodje za selitev ne prenese prvotnih datumov, pa selitev na Exchange Online ustvari novo plast napak na vrhu stare.

Orodja za selitev in ponudniki gostovanja: tvegane kombinacije

Nekatere kombinacije se pri selitvah od ponudnikov skupnega gostovanja pojavljajo zelo pogosto:

• OVH / Infomaniak / Ionos + orodje IMAP v EAC: Microsoftovo domače orodje je priročno, a je znano po tem, da pri obsežnih selitvah IMAP ne ohranja pravilno datumov.
• cPanel (o2switch, LWS, itd.) + BitTitan MigrationWiz v načinu IMAP: MigrationWiz v načinu IMAP doda svoje lastne glave selitve. Rezultat je dokumentiran na strani Popravek datumov selitve BitTitan v Exchange Online.
• Gandi / Mailcow + imapsync: imapsync je zmogljivo orodje, a njegova obravnava INTERNALDATE je odvisna od konfiguracije. Brez ustrezne možnosti datumi niso ohranjeni. Glejte tudi imapsync ni ohranil datumov? Kako jih popraviti.
• Vsaka ročna selitev z vlečenjem in spuščanjem v Outlooku: če je nekdo kopiral cele mape z drag-and-drop med dvema računoma, konfiguriranim v Outlooku, je bil INTERNALDATE vsakega e-poštnega sporočila prepisal z datumom kopiranja. Brez izjeme.

Skupni imenovalec: vse te metode privedejo do Exchange Online z e-poštnimi sporočili, katerih prikazani datum v Outlooku ne ustreza ničemur realnemu.

Zakaj je "sam bom popravil" slaba ideja v velikem obsegu

Razumeti težavo je eno. Popraviti 8.000 e-poštnih sporočil, razporejenih v 40 nabiralnikih Exchange Online, na računih s kompleksnimi mapnimi strukturami, sporočili, podpisanimi s S/MIME, obsežnimi prilogami in gnezdenimi pogovornimi nitmi, je povsem nekaj drugega.

Skript PowerShell, ki deluje na desetih testnih e-poštnih sporočilih, lahko tiho odpove pri sporočilu številka 4237 zaradi nepravilne meje MIME ali glave, kodirane po RFC 2047 (ta format =?UTF-8?B?...?= za znake, ki niso ASCII, v imenih pošiljateljev). Brez mehanizma za individualno preverjanje tega ne boste vedeli. Preprosto boste imeli izgubljeno e-poštno sporočilo.

Konkretna tveganja DIY pristopa pri tej vrsti selitve:

• Podvojena sporočila, če logika vstavljanja odpove na polovici poti
• Manjkajoče priloge, če je struktura multipart slabo sestavljena
• Pokvarjene pogovorne niti v Outlooku (pogovori temeljijo na glavah References: in In-Reply-To:, ki so lahko spremenjene)
• Napake 429 (Too Many Requests) API Microsoft Graph ob 3. uri zjutraj, ki prekinejo obdelavo brez možnosti povrnitve
• Nobenega preprostega načina za preverjanje, ali je bilo vseh 8.000 popravkov pravilno izvedenih

In v posebnem primeru selitev od ponudnikov skupnega gostovanja obstaja dodatna težava: e-poštna sporočila nosijo več plasti parazitskih glav Received:, ne le eno. Preprost skript, ki odstrani "zadnji Received:", ne zadošča. Treba je analizirati celotno verigo, da se ugotovi, katera glava ustreza kateri selitvi, in katera resnično predstavlja izvirni datum prejema.

Kaj Redate.io dela drugače

Vsak uporabnik se prijavi s svojim Microsoftovim računom, in Redate.io odpre samo ta nabiralnik, s dostopom, ki ga ta prijava dovoljuje. Začetno skeniranje je brezplačno: Redate.io identificira vsa e-poštna sporočila, katerih prikazani datum ne ustreza dejanskemu datumu, in za vsak nabiralnik poda natančno oceno.

Popravek temelji na lastniškem korektivnem mehanizmu, ki analizira celotno verigo glav vsakega sporočila in ne glede na uporabljeno orodje za selitev pravilno rekonstruira metapodatke datumov, tudi kadar se superpozicionira več plasti poškodbe. Vsako popravljeno e-poštno sporočilo je preverjeno individualno. Izvirnikov Redate.io ne izbriše: ostanejo v vidni mapi vašega poštnega predala, dokler jih ne izbrišete sami.

Za selitve od ponudnikov skupnega gostovanja večstopenjski analitični cevovod Redate.io izrecno obravnava scenarije dvojne poškodbe: ne gleda le zadnje glave Received:, temveč gre nazaj skozi celotno zgodovino, da poišče resnični datum prejema. Glejte tudi Popravek datumov po selitvi Microsoft 365 za splošen pregled, in IMAP INTERNALDATE: zakaj se datumi pokvarijo za razumevanje osnovne mehanike.

Pred selitvijo ali po njej: dva trenutka za ukrepanje

Dve situaciji, dve drži.

Še niste selili. Dobra novica: škodo je mogoče omejiti. Nekatera orodja za selitev (MigrationWiz v načinu Exchange, CloudM s pravimi možnostmi) bolje ohranjajo datume kot druga. A celo v najboljšem primeru bo selitev od ponudnika skupnega gostovanja brez čiste zgodovine verjetno pustila sledi. Predvidite prehod prek Redate.io po selitvi, preden nabiralniki izročite uporabnikom.

Že ste selili in zahtevki prihajajo. Redate.io popravi obstoječe nabiralniki v Microsoft 365, ne glede na to, kdaj je bila selitev izvedena. Skeniranje vam bo dalo natančno sliko dejanskega stanja vsakega nabiralnika pred kakršnim koli posegom. Oglejte si tudi kontrolni seznam selitve e-pošte, da se izognete enakim težavam v prihodnje.

Ste selili z OVH, Infomaniak, Ionos ali o2switch na Microsoft 365 in datumi so napačni? Ustvarite račun Redate.io za brezplačno skeniranje nabiralnikov in oglejte si natančen obseg škode, preden se odločite za karkoli.