Kopējais hostings uz Microsoft 365: datumu problēma

Problēma, par kuru neviens jums nestāstīja

Jūs tikko pabeidzāt e-pasta migrāciju no OVH, Infomaniak, Ionos vai o2switch uz Microsoft 365. EAC (Exchange Admin Center) migrācijas rīks darbojās visu nakti, viss ir zaļš, pastkastes ir piepildītas. Pirmdienas rītā pirmais pieteikums: "Visiem maniem vecajiem e-pastiem ir šodienas datums." Tad otrs. Tad desmit.

Tā nav Microsoft 365 kļūda. Tā arī nav nejaušība. Tas ir IMAP migrācijas mehānisks rezultāts, un kopējā hostinga gadījumā problēma bieži ir divreiz nopietnāka nekā parastas migrācijas gadījumā. Lūk, kāpēc.

Kā IMAP apstrādā datumus (un kur viss iet greizi)

Katram IMAP serverī saglabātam e-pastam ir divi atšķirīgi datēšanas veidi. No vienas puses, Date: galvene (definēta RFC 2822 standartā), kas atrodas paša ziņojuma saturā un norāda, kad ziņojums tika nosūtīts vai saņemts. No otras puses, INTERNALDATE - servera līmeņa metadati, kas norāda, kurā datumā šis ziņojums tika ievietots pastkastē. Tieši šo vērtību e-pasta klienti kā Outlook izmanto pēc noklusējuma e-pastu kārtošanai un attēlošanai.

(Starp citu, ja esat jebkad mēģinājuši lasīt e-pasta neapstrādātās galvenes EAC, jūs zināt, ka tas nav tieši pludmales lasījums. Pirms satura ir vismaz divdesmit līdz trīsdesmit galveņu rindiņas.)

Kad IMAP migrācijas rīks pārsūta ziņojumu no vienas pastkastes uz citu, tam ir jāatveido šis INTERNALDATE galamērķī. Daži rīki to dara pareizi. Daudzi to nedara vai to dara ar ierobežojumiem. Saņemšanas serveris no savas puses saglabā to, kas tam nodots: ja kopija saglabā savu sākotnējo datumu, Exchange Online šo datumu paglabā. Tāpēc, ja datumi izrādās nepareizi, jāskatās uz rīku, ne uz Microsoft 365.

Rezultāts: katrs migrētais e-pasts šķiet "saņemts" migrācijas dienā. Neatkarīgi no tā, vai tas datēts ar 2019. gadu.

Divpakāpju scenārijs: kāpēc kopējais hostings visu pasliktina

Šeit situācija kļūst patiešām sarežģīta migrācijām no kopējā hostinga pakalpojumu sniedzējiem kā OVH, Infomaniak, Gandi, Ionos vai o2switch.

Šie hostinga pakalpojumu sniedzēji parasti izmanto kopējos Postfix, Dovecot vai cPanel serverus ar standarta IMAP konfigurācijām. Daudzi mazie un vidējie uzņēmumi tur ir uzkrājuši gadus ilgus e-pastus, dažreiz kopš 2010. vai 2012. gada. Kad viņi nolemj pāriet uz Microsoft 365, migrācija bieži notiek divos posmos.

1. posms: pirmā bojāšana (pirms Microsoft 365)

Daudzos gadījumos e-pasti jau ir piedzīvojuši pirmo migrāciju. Uzņēmums gadu gaitā mainīja kopējo hostingu vienu vai divas reizes: no Gandi uz OVH 2018. gadā, pēc tam no OVH uz Infomaniak 2022. gadā, piemēram. Katrs IMAP pārsūtījums varēja atiestatīt sākotnējo INTERNALDATE uz pārsūtīšanas dienu (ja rīks nenodeva sākotnējo datumu), un daži rīki turklāt pievieno savas migrācijas galvenes, kas datētas ar to pašu dienu.

Kad e-pasti nonāk Microsoft 365, tie tātad jau nes rētas. Sākotnējā Date: galvene ir neskarta (tā ir ziņojuma satura daļa, neviens to nepieskar), bet datuma metadati jau ir bijuši traucēti vienu reizi.

2. posms: otrā bojāšana, pārejot uz Exchange Online

EAC IMAP migrācijas rīks vai trešās puses rīks kā BitTitan MigrationWiz IMAP režīmā tad apstrādā šos jau bojātos e-pastus. Ja šis rīks arī nenodod katra e-pasta sākotnējo datumu, Exchange Online e-pastu klasificē pēc pārsūtīšanas dienas, un tas ir "saņemšanas datums", ko Outlook tad parāda.

E-pasts, kas nosūtīts 2017. gada martā, var nest divus nepareizu datumu slāņus: migrācijas galvenes, kas palikušas no 2022. gada pārcelšanas, un saņemšanas datumu no 2024. gada migrācijas uz Microsoft 365. Outlook rāda 2024. Lietotājs redz 2024. Tas ir nepareizi divos līmeņos.

Precizitātes labad: tas ne vienmēr ir jaunākais Received: galvenes ieraksts, ko izmanto. Outlook nosaka attēlošanas datumu, pamatojoties uz Exchange Online pastkastes INTERNALDATE un esošo galveņu kombināciju. Bet, ja migrācijas rīks nenodod sākotnējos datumus, pārcelšanās uz Exchange Online pievieno jaunu kļūdu slāni virs vecā.

Migrācijas rīki un hostingi: riskantas kombinācijas

Dažas kombinācijas parādās ļoti bieži migrācijās no kopējā hostinga:

• OVH / Infomaniak / Ionos + EAC IMAP rīks: Microsoft natīvais rīks ir ērts, bet ir bēdīgi slavens ar to, ka lieljoma IMAP migrāciju laikā pareizi nesaglabā datumus.
• cPanel (o2switch, LWS u.c.) + BitTitan MigrationWiz IMAP režīmā: MigrationWiz IMAP režīmā pievieno savas migrācijas galvenes. Rezultāts ir dokumentēts, cita starpā, mūsu lapā par BitTitan datumu labošanu Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync ir jaudīgs rīks, bet tā INTERNALDATE apstrāde ir atkarīga no konfigurācijas. Bez pareizās opcijas datumi netiek saglabāti. Skatiet arī imapsync: datumi nav saglabāti.
• Jebkura manuāla vilkšanas un nomešanas migrācija Outlook: ja kāds kopēja veselus mapju kokus, veicot vilkšanu un nomešanu starp diviem Outlook konfigurētiem kontiem, katra e-pasta INTERNALDATE tiek pārrakstīts uz kopēšanas datumu. Bez izņēmumiem.

Kopīgais saucējs: visas šīs metodes Exchange Online atstāj e-pastus, kuru Outlook attēlotais datums vairs neatbilst nekam reālam.

Kāpēc "pašam labot" ir slikta ideja lielos apmēros

Saprast problēmu ir viena lieta. Labot 8000 e-pastus, kas sadalīti 40 Exchange Online pastkastēs ar sarežģītām mapju struktūrām, S/MIME parakstītiem e-pastiem, lieliem pielikumiem un ligzdotiem diskusiju pavedienimiem, ir pavisam cita lieta.

PowerShell skripts, kas šķiet darbojas uz desmit testa e-pastiem, var klusi avarēt uz 4237. ziņojuma bojātas MIME robežas vai RFC 2047 kodētas galvenes dēļ (tas =?UTF-8?B?...?= formāts non-ASCII rakstzīmēm sūtītāju vārdos). Bez individuālas pārbaudes mehānisma jūs to nezināsit. Vienkārši būs pazudis viens e-pasts.

Konkrēti DIY riski šāda veida migrācijā:

• Dublēti ziņojumi, ja ievietošanas loģika avarē pusceļā
• Trūkstoši pielikumi, ja multipart struktūra tiek nepareizi rekonstruēta
• Bojāti diskusiju pavedieni Outlook (sarunas balstās uz References: un In-Reply-To: galvenēm, kuras var tikt mainītas)
• 429 (Too Many Requests) kļūdas no Microsoft Graph API pulksten 3:00 naktī, kas pārtrauc apstrādi bez atgriešanās iespējas
• Nav vienkārša veida pārbaudīt, vai visi 8000 labojumi tika pareizi piemēroti

Un kopējā hostinga migrāciju gadījumā ir papildu sarežģījums: e-pasti nes vairākus parazītisku Received: galveņu slāņus, nevis tikai vienu. Vienkāršs skripts, kas noņem "pēdējo Received:" nepietiek. Ir jāanalizē pilnā ķēde, lai identificētu, kura galvene atbilst kurai migrācijai, un kura patiešām pārstāv sākotnējo saņemšanas datumu.

Ko Redate.io dara savādāk

Katrs lietotājs pierakstās ar savu Microsoft kontu, un Redate.io atver tieši šo pastkasti ar piekļuvi, ko šī pierakstīšanās piešķir. Sākotnējā skenēšana ir bezmaksas: Redate.io identificē visus e-pastus, kuru attēlotais datums neatbilst reālajam datumam, un sniedz precīzu novērtējumu katrā pastkastē.

Labošana balstās uz Redate.io izstrādātu korekcijas dzinēju, kas analizē katras ziņojuma pilno galveņu ķēdi, strādā neatkarīgi no izmantotā migrācijas rīka, un pareizi rekonstruē datuma metadatus pat tad, kad vairāki bojāšanas slāņi pārklājas. Katrs labotais e-pasts tiek individuāli pārbaudīts. Oriģināli tiek saglabāti redzamā rezerves mapē, līdz jūs tos paši izdzēšat.

Kopējā hostinga migrācijām Redate.io daudzpakāpju analīzes konveijers eksplicīti apstrādā dubultās bojāšanas scenārijus: tas neaprobežojas ar pēdējās Received: galvenes aplūkošanu, tas pārskata vēsturi, lai atrastu reālo saņemšanas datumu. Skatiet arī, kā labot datumus pēc Microsoft 365 migrācijas vispārīgi, un īpašo pamācību par bojātiem IMAP INTERNALDATE pamatmehānisma izprašanai.

Pirms vai pēc migrācijas: divi momenti rīcībai

Divas situācijas, divas pieejas.

Jūs vēl neesat migrējuši. Labā ziņa: zaudējumus var ierobežot. Daži migrācijas rīki (MigrationWiz Exchange režīmā, CloudM ar pareizajām opcijām) labāk saglabā datumus nekā citi. Taču pat labākajā gadījumā migrācija no kopējā hostinga bez tīras vēstures atstās pēdas. Plānojiet Redate.io izmantošanu pēc migrācijas, pirms nododat pastkastes lietotājiem.

Jūs jau esat migrējuši un pieteikumi plūst. Redate.io labo esošās Microsoft 365 pastkastes neatkarīgi no migrācijas vecuma. Skenēšana dos precīzu priekšstatu par katras pastkastes reālo stāvokli pirms jebkādas iejaukšanās. Skatiet arī e-pasta migrācijas kontrolsarakstu, lai izvairītos no tām pašām problēmām nākotnē.

Jūs migrējāt no OVH, Infomaniak, Ionos vai o2switch uz Microsoft 365 un datumi ir nepareizi? Izveidojiet Redate.io kontu, lai bezmaksas skenētu savas pastkastes un redzētu precīzu bojājumu apmēru, pirms pieņemat jebkādus lēmumus.