Jagatud hostimine Microsoft 365-i: peidetud kuupäevaprobleem

Probleem, millest keegi teile ei rääkinud

Olete just lõpetanud meilide migreerimise OVH, Infomaniak, Ionos või o2switch'i serverist Microsoft 365-i. EAC (Exchange Admin Center) migratsioonitööriist töötas terve öö, kõik on roheline, postkastid on täis. Esmaspäeva hommikul tuleb esimene pilet: „Kõik mu vanad meilid on tänase kuupäevaga." Siis teine. Siis kümme.

See ei ole Microsoft 365 viga. Samuti pole see juhus. See on IMAP-migreerimise mehaaniline tagajärg, ja jagatud hostimise puhul on probleem sageli kaks korda tõsisem kui tavalises migreerimises. Siin on põhjus.

Kuidas IMAP kuupäevadega töötab (ja kus see läheb valesti)

Igal IMAP-serveris salvestatud meilil on kaks erinevat kuupäevatüüpi. Ühest küljest on Date: päis (defineeritud RFC 2822-s), mis asub sõnumi sisus endas ja näitab, millal sõnum saadeti või vastu võeti. Teisest küljest on INTERNALDATE, serveri tasandi metaandmed, mis näitavad, millal see sõnum postkasti lisati. Outlook ja teised meilikliendid kasutavad just seda väärtust meilide vaikimisi sorteerimiseks ja kuvamiseks.

(Muide, kui olete kunagi püüdnud lugeda toore meili päiseid EAC-is, siis teate, et see pole täpselt rannalugemine. Enne sisu jõudmist on kergesti kakskümmend kuni kolmkümmend päiserida.)

Kui IMAP-migreerimistööriist kannab sõnumi ühest postkastist teise, peab ta sihtserveris selle INTERNALDATE uuesti looma. Mõned tööriistad teevad seda õigesti. Paljud ei tee, või teevad seda piirangutega. Ja sihtserveril on oma sõna öelda: kui koopia kannab oma algset kuupäeva, säilitab Exchange Online selle kuupäeva. Kui kuupäevad on valed, tasub vaadata tööriista, mitte Microsoft 365-t.

Tulemus: iga migreeritud meil näib olevat „vastu võetud" migreerimise päeval. Pole tähtis, et see pärineb aastast 2019.

Kaheetapiline riknemise stsenaarium: miks jagatud hostimisest migreerimine kõike süvendab

Siin muutub olukord tõeliselt problemaatiliseks OVH, Infomaniak, Gandi, Ionos või o2switch'i jagatud hostimisteenustest migreerimisel.

Need teenusepakkujad kasutavad tavaliselt jagatud Postfix, Dovecot või cPanel servereid standardse IMAP-konfiguratsiooniga. Paljud VKEd on sinna kogunud aastaid meile, mõnikord alates 2010. või 2012. aastast. Kui nad otsustavad üle minna Microsoft 365-ile, toimub migreerimine sageli kahes etapis.

1. etapp: esimene riknemine (enne Microsoft 365-i jõudmist)

Paljudel juhtudel on meilid juba läbinud ühe migreerimise. Ettevõte on aastate jooksul vahetanud jagatud hostimisteenust üks-kaks korda: Gandilt OVH-le 2018. aastal, seejärel OVH-lt Infomaniak'ile 2022. aastal, näiteks. Iga IMAP-ülekanne võis nullida algse INTERNALDATE väärtuse ülekande kuupäevale, kui tööriist ei kandnud üle algset kuupäeva, ja mõned tööriistad lisavad ka oma migreerimispäiseid, mis on ajatemplitud selle kuupäevaga.

Kui meilid Microsoft 365-i jõuavad, kannavad nad juba armistusi. Algne Date: päis on puutumatu (see on sõnumi sisu osa, keegi seda ei puuduta), kuid kuupäeva metaandmed on juba esimest korda häiritud.

2. etapp: teine riknemine Exchange Online'i ülekandmisel

EAC IMAP-migreerimistööriist või kolmanda osapoole tööriist nagu BitTitan MigrationWiz IMAP-režiimis neelab siis need juba kahjustatud meilid. Kui see tööriist ei kanna üle ka iga meili algset kuupäeva, määrab Exchange Online meilile ülekande kuupäeva, ja see saab Outlookis kuvatavaks „vastuvõtmise kuupäevaks".

Märtsis 2017 saadetud meil võib seega kanda kaht kihti valesid kuupäevi: 2022. aasta vahemigreerimise jäetud päiseid ja Microsoft 365-i 2024. aasta migreerimise vastuvõtmise kuupäeva. Outlook kuvab 2024. Kasutaja näeb 2024. See on vale kahel tasandil.

Täpsuse huvides: see ei ole alati kõige uuem Received: päis, mida kasutatakse. Outlook määrab kuvamise kuupäeva Exchange Online'i postkasti INTERNALDATE ja olemasolevate päiste kombinatsiooni põhjal. Kuid kui migreerimistööriist ei kanna üle algseid kuupäevi, lisab Microsoft 365-i migreerimine uue veakihi vana peale.

Migreerimistööriistad ja hostimisplatvormid: riskantsed kombinatsioonid

Jagatud hostimisest migreerimisel korduvad mõned kombinatsioonid väga sageli:

• OVH / Infomaniak / Ionos + EAC IMAP-tööriist: Microsofti natiivne tööriist on mugav, kuid tuntud selle poolest, et ei säilita mahukate IMAP-migreerimiste puhul kuupäevi korrektselt.
• cPanel (o2switch, LWS, jne) + BitTitan MigrationWiz IMAP-režiimis: MigrationWiz IMAP-režiimis lisab oma migreerimispäised. Tulemus on dokumenteeritud, muuhulgas lehel BitTitani migratsioonikuupäevade parandamine Microsoft 365-s.
• Gandi / Mailcow + imapsync: imapsync on võimas tööriist, kuid selle INTERNALDATE haldamine sõltub konfiguratsioonist. Ilma sobiva suvandita ei säilitata kuupäevi. Vaata ka imapsync ei säilitanud kuupäevi.
• Kõik käsitsi lohistamisega tehtud migreerimised Outlookis: kui keegi kopeeris terveid kaustu kahe Outlookis konfigureeritud konto vahel lohistades, kirjutatakse iga meili INTERNALDATE kopeerimise kuupäevaga üle. Eranditult.

Ühine nimetaja: kõik need meetodid viivad Exchange Online'i meilideni, mille Outlookis kuvatud kuupäev ei vasta enam millelelegi tegelikule.

Miks „ise parandamine" on suures mahus halb mõte

Probleemi mõistmine on üks asi. 8000 meili parandamine 40 Exchange Online'i postkastis, keerukate kaustastruktuuride, S/MIME-allkirjastatud meilide, suurte manuste ja pesastatud vestluslõimede puhul on hoopis teine lugu.

PowerShelli skript, mis tundub töötavat kümne testmeilil, võib vaikselt ebaõnnestuda meilil number 4237, kuna tegemist on rikutud MIME-piiriga või RFC 2047-ga kodeeritud päisega (see =?UTF-8?B?...?= formaat mitte-ASCII-märkide jaoks saatjate nimedes). Ilma individuaalse verifitseerimismehhanismita te seda ei tea. Teil on lihtsalt üks meil kadunud.

Konkreetsed riskid ise tegemise puhul seda tüüpi migreerimises:

• Duplikaatsõnumid, kui lisamisloogika ebaõnnestub poolel teel
• Puuduvad manused, kui multipart-struktuur rekonstrueeritakse valesti
• Katkised vestluslõimed Outlookis (vestlused põhinevad References: ja In-Reply-To: päistel, mida saab muuta)
• 429-vead (Too Many Requests) Microsofti serverilt kell kolm öösel, mis katkestavad töötlemise ilma tagasipöördumiseta
• Pole lihtsat viisi kontrollimaks, et kõik 8000 parandust rakendati õigesti

Ja jagatud hostimisest migreerimise spetsiifilises puhul on lisaraskus: meilid kannavad mitut kihti parasiteerivaid Received: päiseid, mitte ainult ühte. Lihtne skript, mis eemaldab „viimase Received:", ei piisa. Tuleb analüüsida kogu päiseahela, et tuvastada, milline päis vastab millisele migreerimisele, ja milline esindab tegelikult algset vastuvõtmise kuupäeva.

Mida Redate.io teisiti teeb

Igaüks logib sisse oma Microsofti kontoga, ja Redate.io avab selle ühe postkasti sisselogimisega antud õigustega. Esialgne skannimine on tasuta: Redate.io tuvastab kõik meilid, mille kuvatud kuupäev ei vasta tegelikule kuupäevale, ja annab täpse hinnangu iga postkasti kohta.

Parandamine põhineb Redate'i välja töötatud parandusmootoril, mis analüüsib iga sõnumi täielikku päiseahelat, rekonstrueerib, sõltumata kasutatud migreerimistööriistast, kuupäeva metaandmed korrektselt, isegi kui mitu rikkekihti kattuvad. Iga parandatud meil kontrollitakse individuaalselt. Redate.io ei kustuta originaale kunagi. Need jäävad nähtavasse kausta teie postkastis, kuni te need ise kustutate.

Jagatud hostimisest migreerimiste puhul käsitleb Redate.io mitmeastmeline analüüsipipeline sõnaselgelt topeltriknemise stsenaariume: see ei vaata ainult viimast Received: päist, vaid liigub kogu ajaloos tagasi, et leida tegelik vastuvõtmise kuupäev. Vaata ka, kuidas parandada kuupäevi pärast Microsoft 365 migratsiooni üldiselt, ning spetsiifilist juhendit katkiste IMAP INTERNALDATE mehhanismi mõistmiseks.

Enne või pärast migreerimist: kaks hetke tegutsemiseks

Kaks olukorda, kaks lähenemist.

Te pole veel migreerinud. Hea uudis: kahju saab piirata. Mõned migreerimistööriistad (MigrationWiz Exchange-režiimis, CloudM sobivate seadetega) säilitavad kuupäevi paremini kui teised. Kuid isegi parimal juhul jätab migreerimine jagatud hostimisplatvormist ilma puhta ajaloota tõenäoliselt jälgi. Planeerige Redate.io kasutamine pärast migreerimist, enne kui postkastid kasutajatele üle antakse.

Olete juba migreerinud ja piletid tulevad sisse. Redate.io parandab olemasolevad postkastid Microsoft 365-is, sõltumata migreerimise vanusest. Skannimine annab täpse ülevaate iga postkasti tegelikust seisust enne mis tahes sekkumist. Vaata ka e-posti migreerimise kontrollnimekirja, et vältida samu probleeme tulevikus.

Migreerisid OVH, Infomaniak, Ionos või o2switch'ilt Microsoft 365-i ja kuupäevad on valed? Looge Redate.io konto, et skannida oma postkaste tasuta ja näha täpselt kahjustuste ulatust enne otsuse tegemist.