Bendras hostingas į Microsoft 365: paslėpta datų problema

Problema, apie kurią niekas neperspėjo

Ką tik baigėte perkelti el. paštą iš OVH, Infomaniak, Ionos ar o2switch į Microsoft 365. Migracijos vedlys EAC (Exchange Admin Center) dirbo visą naktį, viskas žalia, dėžutės užpildytos. Pirmadienio rytas, pirmas bilietas: „Visi mano seni laiškai rodo šiandienos datą." Tada antras. Tada dešimt.

Tai nėra Microsoft 365 klaida. Tai taip pat nėra atsitiktinumas. Tai mechaninis IMAP migracijos rezultatas, o bendro hostingo atveju problema dažnai yra dvigubai rimtesnė nei įprastos migracijos metu. Štai kodėl.

Kaip IMAP tvarko datas (ir kur viskas subyra)

Kiekvienas el. laiškas, saugomas IMAP serveryje, turi du atskirus datavimo tipus. Viena vertus, antraštė Date: (apibrėžta RFC 2822), esanti paties laiško turinyje, nurodanti, kada žinutė buvo išsiųsta ar gauta. Kita vertus, INTERNALDATE - serverio lygio metaduomenys, nurodantys, kada šis laiškas buvo įdėtas į dėžutę. Būtent šią reikšmę el. pašto klientai, tokie kaip Outlook, naudoja pagal numatytuosius nustatymus laiškams rūšiuoti ir rodyti.

(Beje, jei kada bandėte skaityti neapdorotas el. laiško antraštes EAC aplinkoje, žinote, kad tai tikrai nėra paplūdimio skaitymas. Lengvai susidarys dvidešimt ar trisdešimt eilučių antraščių, kol pasieksite turinį.)

Kai IMAP migracijos įrankis perkelia žinutę iš vienos dėžutės į kitą, jis turi iš naujo sukurti INTERNALDATE paskirties serveryje. Kai kurie įrankiai tai daro teisingai. Daugelis - ne, arba daro su apribojimais. Be to, priimantis serveris išsaugo tai, kas jam perduota: kai kopija atkeliauja su savo pradine data, Exchange Online šią datą ir palaiko. Todėl kai datos rodomos neteisingai, žiūrėti reikia į įrankį, o ne į Microsoft 365.

Rezultatas: kiekvienas perkeltas laiškas atrodo tarsi gautas migracijos dieną. Nesvarbu, kad jis datuotas 2019 metais.

Dviejų žingsnių scenarijus: kodėl bendras hostingas viską apsunkina

Čia situacija tampa tikrai problemiška migruojant iš bendro hostingo tiekėjų, tokių kaip OVH, Infomaniak, Gandi, Ionos ar o2switch.

Šie tiekėjai paprastai naudoja bendrus Postfix, Dovecot ar cPanel serverius su standartinėmis IMAP konfigūracijomis. Daug smulkaus ir vidutinio verslo įmonių ten kaupė laiškus daugelį metų, kartais nuo 2010 ar 2012 metų. Kai jos nusprendžia pereiti prie Microsoft 365, migracija dažnai vyksta dviem etapais.

1 etapas: pirmasis sugadinimas (dar prieš Microsoft 365)

Daugeliu atvejų laiškai jau yra patyrę pirmą migraciją. Įmonė keitė bendro hostingo tiekėją kartą ar du per metus: iš Gandi į OVH 2018-aisiais, paskui iš OVH į Infomaniak 2022-aisiais, pavyzdžiui. Kiekvienas IMAP perkėlimas galėjo nustatyti pradinį INTERNALDATE į perkėlimo dieną, jei įrankis neperdavė pradinės datos, o kai kurie įrankiai papildomai palieka savo migracijos antraštes su tos dienos laiko žyma.

Kai laiškai pasiekia Microsoft 365, jie jau neša randus. Pradinė antraštė Date: yra nepažeista (ji yra laiško turinio dalis, niekas jos neliečia), tačiau datų metaduomenys jau buvo sutrikdyti pirmą kartą.

2 etapas: antrasis sugadinimas pereinant į Exchange Online

EAC IMAP migracijos įrankis arba trečiosios šalies įrankis, kaip BitTitan MigrationWiz, sukonfigūruotas IMAP režimu, tuomet įtraukia šiuos jau sugadintus laiškus. Jei šis įrankis taip pat neperduoda kiekvieno laiško pradinės datos, Exchange Online priskiria laiškui perkėlimo dienos datą, ir tą „gavimo datą" Outlook aplinkoje ir rodo.

Laiškas, išsiųstas 2017 metų kovo mėnesį, gali turėti du klaidingų datų sluoksnius: migracijos antraštes, likusias po 2022-ųjų perkėlimo, ir gavimo datą iš 2024-ųjų migracijos į Microsoft 365. Outlook rodo 2024. Vartotojas mato 2024. Tai klaidinga dviem lygiais.

Tiksliau sakant, ne visada pati naujausia Received: antraštė yra naudojama. Outlook nustato rodymo datą remdamasis Exchange Online dėžutės INTERNALDATE ir esamų antraščių deriniu. Tačiau kai migracijos įrankis neperduoda pradinių datų, perkėlimas į Exchange Online sukuria naują klaidų sluoksnį ant senojo.

Migracijos įrankiai ir hostingo tiekėjai: rizikingos kombinacijos

Kelios kombinacijos itin dažnai pasitaiko migracijos iš bendro hostingo metu:

• OVH / Infomaniak / Ionos + EAC IMAP įrankis: Microsoft gimtasis įrankis yra patogus, tačiau pagarsėjęs tuo, kad tinkamai neišsaugo datų didelės apimties IMAP migracijų metu.
• cPanel (o2switch, LWS ir kt.) + BitTitan MigrationWiz IMAP režimu: MigrationWiz IMAP režimu prideda savo migracijos antraštes. Rezultatas dokumentuotas, be kita ko, mūsų puslapyje BitTitan migracijos datų taisymas Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync yra galingas įrankis, tačiau jo INTERNALDATE valdymas priklauso nuo konfigūracijos. Be tinkamos parinkties, datos neišsaugomos. Taip pat žiūrėkite imapsync neišsaugojo datų.
• Bet kokia rankinė migracija vilkimu Outlook aplinkoje: jei kas nors kopijavo ištisus aplankus tempiant ir numesdamas tarp dviejų Outlook sukonfigūruotų paskyrų, kiekvieno laiško INTERNALDATE perrašomas į kopijavimo datą. Be išimčių.

Bendras vardiklis: visi šie metodai Exchange Online pateikia laiškus, kurių Outlook rodoma data nebeatitinka nieko realaus.

Kodėl "taisyti pačiam" yra bloga idėja dideliu mastu

Suprasti problemą yra viena. Ištaisyti 8000 laiškų, paskirstytų po 40 Exchange Online dėžučių, paskyrų su sudėtingomis aplankų struktūromis, S/MIME pasirašytais laiškais, dideliais priedais ir įterptomis pokalbių gijomis, yra visai kas kita.

PowerShell skriptas, kuris atrodo veikiantis su dešimčia bandomųjų laiškų, gali tyliai sugestis ties 4237-uoju laišku dėl sugadintų MIME ribų arba RFC 2047 koduotoje antraštėje (tas formatas =?UTF-8?B?...?= ne-ASCII simboliams siuntėjų varduose). Be individualaus patikrinimo mechanizmo, to nežinosite. Tiesiog prarasite laišką.

Praktinės DIY rizikos tokio tipo migracijose:

• Dubliuoti laiškai, jei įterpimo logika sugestų viduryje proceso
• Trūkstami priedai, jei multipart struktūra bus netinkamai atkurta
• Sutrikdytos pokalbių gijos Outlook aplinkoje (pokalbiai remiasi antraštėmis References: ir In-Reply-To:, kurios gali būti pakeistos)
• 429 klaidos (Too Many Requests) iš Microsoft Graph API 3 valandą ryto, kurios nutraukia apdorojimą be galimybės atšaukti
• Jokio paprasto būdo patikrinti, ar visi 8000 pataisymų buvo pritaikyti teisingai

O konkrečiai bendro hostingo migracijų atveju, yra papildomas sunkumas: laiškai neša kelis parazitinių Received: antraščių sluoksnius, o ne tik vieną. Paprastas skriptas, kuris pašalina „paskutinę Received:" antraštę, nepakanka. Reikia išanalizuoti visą grandinę, kad nustatytumėte, kuri antraštė atitinka kurią migraciją ir kuri iš tikrųjų atspindi pradinę gavimo datą.

Ką Redate.io daro kitaip

Kiekvienas vartotojas prisijungia savo Microsoft paskyra, ir Redate.io atveria tą pačią dėžutę su prisijungimo suteikiamomis teisėmis. Pradinis nuskaitymas yra nemokamas: Redate.io identifikuoja visus laiškus, kurių rodoma data neatitinka realios datos, ir pateikia tikslią kiekvienos dėžutės įvertinimą.

Taisymas remiasi Redate.io sukurtu varikliu, kuris analizuoja kiekvieno laiško antraščių grandinę, nepriklausomai nuo naudoto migracijos įrankio, ir teisingai atkuria datų metaduomenis, net kai keli sugadinimo sluoksniai persikloja. Kiekvienas ištaisytas laiškas tikrinamas individualiai. Pradiniai laiškai saugomi matomame atsarginės kopijos aplanke, kol jų nepašalinsite patys.

Migracijų iš bendro hostingo atveju Redate.io daugiapakopis analizės srautas aiškiai tvarko dvigubo sugadinimo scenarijus: jis neapsiriboja tik paskutinės Received: antraštės patikrinimu, bet peržiūri visą istoriją, kad rastų tikrąją gavimo datą. Taip pat skaitykite, kaip pataisyti datas po Microsoft 365 migracijos apskritai, ir specialų vadovą apie sugadintus IMAP INTERNALDATE, kad suprastumėte pagrindinę mechaniką.

Prieš migraciją ar po jos: du momentai veikti

Dvi situacijos, dvi pozicijos.

Dar nemigravo. Gera žinia: galima apriboti žalą. Kai kurie migracijos įrankiai (MigrationWiz Exchange režimu, CloudM su tinkamomis parinktimis) geriau išsaugo datas nei kiti. Tačiau net geriausiu atveju migracija iš bendro hostingo be švarios istorijos greičiausiai paliks pėdsakų. Planuokite Redate.io naudojimą po migracijos, prieš perduodant dėžutes vartotojams.

Jau migravote ir bilietai plaukia. Redate.io taiso esamas Microsoft 365 dėžutes, nepriklausomai nuo migracijos senumo. Nuskaitymas pateiks tikslų kiekvienos dėžutės realios būklės vaizdą prieš bet kokį veiksmą. Taip pat peržiūrėkite el. pašto migracijos kontrolinį sąrašą, kad ateityje išvengtumėte tų pačių problemų.

Migravote iš OVH, Infomaniak, Ionos ar o2switch į Microsoft 365 ir datos klaidingos? Sukurkite Redate.io paskyrą ir nemokamai nuskanuokite savo dėžutes, kad tiksliai pamatytumėte žalos mastą prieš priimant bet kokį sprendimą.