CloudM Migrate: korjaa vaaarat sahkopostipaivat

CloudM Migraten paivamaaraongelma, josta kukaan ei varoita

CloudM Migrate on valmis. Hallintapaneeli nayttaa 100 % valmis, kaikki kayttajat siirretty, nolla virhetta. Projektin tiketti suljetaan ja siirrytaan seuraavaan asiakkaaseen.

Viikon kuluttua IT-johtaja soittaa. "Miksi jokainen sahkoposti postilaatikossani nayttaa 2. huhtikuuta?"

Ei jotkut sahkopostit. Kaikki. Viisi vuotta asiakaskirjeenvaihtoa, oikeudellisia asiakirjoja, HR-tietueita, ostotilauksia vuodelta 2020, kaikki nayttavat paivamaaran, jolloin CloudM suoritti siirron. Viestit ovat tallella, sisalto on ehjaa, liitteet ovat kunnossa. Mutta paivamaaarat ovat vaarin joka ikisessa.

Tama ei ole CloudM-virhe. CloudMin oma tukidokumentaatio myontaa sen avoimesti. Ongelma on siirtotyokalujen viestinsiirtotavan ja kohde-sahkopostipalvelimien saapuvien viestien metatietojen kasittelytavan risteymassa. Mutta taman tietaminen ei auta asiakastasi, jonka postilaatikosta on tullut mahdoton jarjestaa kronologisesti.

Miten CloudM todellisuudessa siirtaa sahkopostiviesteja

CloudM Migrate yhdistaa lahde- ja kohdealustoihin niiden API:en kautta. Google Workspacen tapauksessa tama tarkoittaa palvelutilia, jolla on koko verkkotunnuksen kattava delegointi (maaritetty Google Admin Consolessa Turvallisuus > API-hallinta -kohdassa). Microsoft 365:n tapauksessa CloudM kayttaa joko Exchange Web Services -palvelua tai Microsoft Graph APIa siirtopolusta riippuen.

Kun CloudM lukee viestin lahteesta, se saa taydellisen RFC 2822 -sisallon, mukaan lukien kaikki alkuperaiset otsikot ja viestin rungon. Alkuperainen Date:-otsikko (se jonka lahettajan sahkopostipalvelin leimasi sahkopostin lahetyksessa) tulee mukana ehjana. Samoin kaikki alkuperaiset Received:-otsikot, jotka jaljittavat viestin toimitusreitin.

Ongelma syntyy kohteessa. Kun CloudM kirjoittaa viestin kohdepostilaatikkoon, kohdepalvelin kasittelee sen uutena toimituksena. Se leimaa tuoreen Received:-otsikon nykyisella paivamaaralla ja kellonajalla, ja asettaa INTERNALDATE:n (IMAP:n jarjestelyyn kayttaman aikaleiman) lisaamishetkeen.

Nain otsikoketju nayttaa CloudM-siirron jalkeen Microsoft 365:een:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Vuoden 2019 otsikko on yha tallella. Alkuperainen Date:-otsikko sanoo edelleen 23. syyskuuta 2019. Mutta Outlook lukee ylimman Received:-otsikon nayttojarjestyksen maarittamiseksi, ja se sanoo 2. huhtikuuta 2026.

CloudMin "Strip Received Headers" -asetus

CloudM tarjoaa asetuksen tahan ongelmaan. Kohdealustan lisaasetuksissa Message Options -kohdassa on "Strip Received Headers" -kytkin. Kun se on kaytoossa, CloudM poistaa Received-otsikot ennen viestin lisaamista ja korvaa ne yhdella otsikolla, joka vastaa sahkopostin Date:-otsikkoa.

Kuulostaa ratkaisulta, eiko? Ei aivan.

Ensinnaakin sinun on tiedettava asetuksesta ennen siirron suorittamista. Useimmat yllapitajat loytavat paivamaaraongelman siirron valmistumisen jalkeen. Siina vaiheessa viestit ovat jo kohteessa vaarilla paivamaarilla. CloudMin uudelleenajo asetuksen ollessa kaytoossa luo vain kaksoiskappaleita, se ei korjaa sita mika siella jo on.

Toiseksi talla asetuksella on ehdoton rajoitus, kun Google Workspace on kohde. Googlen oma dokumentaatio vahvistaa: Gmail kirjoittaa aina uudelleen Received:-otsikot API:n kautta lisatyissa viesteissa, leimaten ne lisaysajankohdalla. Tama on alustatasoinen rajoitus, jota CloudM ei voi ohittaa. Jopa "Strip Received Headers" ollessa kaytoossa Google Workspace lisaa oman Received:-otsikkonsa siirtopaivamaaralla.

Microsoft 365 -kohteissa asetus toimii teoriassa paremmin, mutta M365:n kuljetusputkella on oma kayttaytymisensa. Exchange Online voi silti asettaa INTERNALDATE:n oman toimituskasittelynsaa perusteella riippuen siita, miten viesti tulee jarjestelmaan.

Mitka CloudM-siirrot rikkovat paivamaaarat (ja mitka eivat)

Kaikki CloudM-siirrot eivat tuota vaaria paivamaaria. Lopputulos riippuu lahde-kohdeyhdistelmasta ja CloudMin kayttamasta API-polusta:

• Google Workspace Microsoft 365:een: Paivamaaarat rikkoutuvat. CloudM lukee Gmail API:n kautta ja kirjoittaa Exchangeen. M365:n kuljetuskerros leimaa uudet Received-otsikot.
• Microsoft 365 Google Workspaceen: Paivamaaarat rikkoutuvat. Strip Received Headersin kanssa Googlen API kirjoittaa silti Received-otsikon uudelleen lisayspaivamaaralla. CloudMin tukidokumentaatio kutsuu tata "tiukaksi alustarajoitukseksi".
• Google Workspace Google Workspaceen: Paivamaaarat rikkoutuvat. Verkkotunnuksen vaihdot, vuokralaisten yhdistamiset, yritysostofuusiot, kohteen Google-vuokralainen leimaa aina siirtopaivamaaaran saapuviin viesteihin.
• Paikallinen Exchange Microsoft 365:een: Rikkoutuu yleensa IMAP-polun kautta. Jos CloudM kayttaa EWS:aa molemmilla puolilla, paivamaarien sailyttaminen on luotettavampaa mutta ei taattua.
• IMAP-lahde (yleinen) mihin tahansa kohteeseen: Paivamaaarat rikkoutuvat. Kun CloudM yhdistaa yleiseen IMAP-palvelimeen lahteena, kohde lisaa silti omat toimitusotsikkonsa.

Hankala osuus? CloudMin siirtohallintapaneeli ei signaloi mitaan tasta. Edistymispalkki taytyy, tilasarake sanoo "Completed", kappalemaaarat tasmaaavat. CloudMin nakokulmasta siirto onnistui. Ja teknisesti se onnistuikin. Viestit siirrettiin. Paivamaaarat vain eivat selvinneet matkasta.

CloudM Managed vs. Self-Service: sama paivamaaraongelma

CloudM tarjoaa kaksi kayttoonottomallia. SaaS-versio (CloudM Migrate isannoity) toimii kokonaan CloudMin infrastruktuurissa. Itse isannoitu versio antaa ottaa kayttoon ensisijaiset ja toissijaiset siirtopalvelimet omassa verkossasi, Google Cloudissa, Azuressa tai AWS:ssa.

Jotkut MSP:t olettavat, etta itse isannoitu vaihtoehto antaa enemman hallintaa paivamaarien kasittelyyn, koska siirtopalvelimia hallinnoidaan suoraan. Ei anna. Paivamaaraongelma tapahtuu kohdepalvelimella, ei CloudMin kasittelysolmuissa. Olipa siirtofarmisi CloudMin pilvessa tai omassa Azure-VM:ssasi, kohde-sahkopostipalvelin leimaa edelleen siirtopaivamaaaran jokaiseen vastaanottamaansa viestiin.

CloudM tarjoaa myos taysin hallinnoitua "Serviced Migration" -palvelua, jossa heidan tiiminsae hoitaa projektin alusta loppuun. Sama tulos paivamaarien osalta. Tekniikka on identtinen, kaytannossa vain eri kadet nappaimistolla. Oletko koskaan maksanut premium-palvelusta ja saanut silti saman rajoituksen kuin ilmaisessa tasossa? Juuri silta tama tuntuu.

Virheellisten Date-otsikoiden komplikaatio

On viela yksi CloudM-kohtainen kayttaytyminen, joka pahentaa tilannetta. Kun CloudM kohtaa lahdedahkopostin, jonka Date:-otsikko ei noudata RFC 822:ta (virheellinen aikavy6hyke, puuttuva viikonpaiva, ei-standardimuoto), CloudM muokkaa otsikkoa varmistaakseen viestin siirtamisen.

Tama tarkoittaa, etta jotkut sahkopostit menettavat jopa alkuperaisen paivamaaraviitteensa. Muokattu Date:-otsikko ei valttamatta vastaa lainkaan todellista lahetyspaivaa. CloudMin tukidokumentaatio mainitsee taman kayttaytymisen kohdassa "Possible Changes to Migrated Items", mutta ei tarkenna mika muokattu paiva on.

Postilaatikolle, jossa on 12 000 viestia kahdeksan vuoden ajalta, voi olla satoja sahkoposteja, joiden Date-otsikot ovat hieman ei-standardeja (erityisesti viesteja vanhoilta sahkopostipalvelimilta, automatisoiduilta jarjestelmilta tai kansainvaiselta lahettajilta, joilla on aikavyohykkeen muotoiluominaisuuksia). CloudMin muokkauksen ja kohdepalvelimen Received-otsikon uudelleenkirjoituksen jalkeen nailla viesteilla on paivamaaarat, joilla ei ole mitaan yhteista todellisuuden kanssa.

Miksi manuaaliset korjaukset eivat skaalaudu CloudMin jalkeen

Voisiko taman korjata itse? Teknisesti alkuperainen Date:-otsikko on yha upotettuna useimpiin viesteihin (paitsi niihin, jotka CloudM muokkasi RFC-yhteensopivuutta varten). Jotkut yllapitajat ovat yrittaneet kirjoittaa skripteja paivamaarien korjaamiseksi CloudM-siirron jalkeen.

Tassa on taman lahestymistavan todellisuus. Pitaa yhdistaa mahdollisesti tuhansiin postilaatikoihin, joissa kussakin on tuhansia viesteja. Jokaisesta sahkopostista pitaa jasentaa taydellinen otsikoketju, tunnistaa mitka Received:-otsikot CloudM tai kohdepalvelin lisasi, kasitella reunatapaukset (S/MIME-allekirjoitetut viestit joissa otsikkomuutos rikkoo allekirjoituksen, PGP-salattu sisalto, moniosainen MIME-rakenne sisakkaisilla rajoilla, RFC 2047 -koodatut ei-ASCII-otsikot japanilaisilta tai korealaisilta lahettajilta), ja tehda kaikki tama menettamatta yhtaan liitetta tai rikkomatta sahkopostiketjutusta.

Skripti joka toimii 50 testisahkopostilla puhtaasta postilaatikosta ei selvia tuotantoymparistosta, jossa on 40 000 viestia vuosikymmenen ajalta. Mita tapahtuu kun vastaan tulee 47 Mt sahkoposti kuudella sisakkaisella liitteella? Enta API-nopeusrajoitukset (250 kiintioyksikkoa kayttajaa kohti sekunnissa Googlella, Microsoftin rajoitus noin 10 000 pyyntoa 10 minuutissa)? Mika on palautussuunnitelmasi kun jotain menee vikaan viestissa numero 8 347?

Ja todellinen kysymys, jonka useimmat yllapitajat esittavat vasta kun on liian myohaista: miten varmistat, etta jokainen korjattu viesti on todellakin ehjae?

Korjaa CloudM-siirron paivamaaarat Redate.io:lla

Redate.io yhdistaa suoraan kyseisiin postilaatikoihin (Google Workspace, Microsoft 365 tai IMAP) ja skannaa sahkopostit, joissa on CloudMin siirtopaivamaaaran tunniste. Skannaus on ilmainen ja kestaa muutaman minuutin postilaatikkoa kohti. Se nayttaa vaikutettujen viestien tarkan maaran ennen mitaan sitoumusta.

Korjaus kayttaa patentoitua otsikoketjun analysointimoottoria, joka tunnistaa CloudM-kohtaiset siirtokaavat Received-otsikoketjusta. Redate.io suorittaa kohdistetun metatietojen korjauksen muuttamatta viestin sisaltoa, sailyttaen liitteet, ketjutuksen, tarrat, kansiot ja digitaaliset allekirjoitukset. Jokainen korjattu viesti kay lapi yksilollisen varmennuksen, jossa viestin eheys tarkistetaan alkuperaista vasten ennen prosessin jatkamista.

Alkuperaiset sahkopostit sailytetaan nakyvassa Redate.io - Originals -varmuuskopiokansiosssa 30 paivaa. Jos jotain taytyyy perua, alkuperaiset ovat siella postilaatikossa, eivat haudattuna johonkin ulkoiseen arkistoon.

MSP:ille jotka kayttivat CloudMia asiakasymparistoissa, Redate.io kasittelee useiden postilaatikoiden korjaukset laajassa mittakaavassa, samalla viestikohtaisella varmennuksella olipa kyseessa 1 tai 500 postilaatikkoa. CloudMin jattama paivamaaraongelma ei tarvitse tulla asiakkaasi sahkopostiympariston pysyvaksi ominaisuudeksi.

Alustakohtaiset oppaat CloudM-siirroille

Korjausprosessi mukautuu kohdealustaan. Redate.io kasittelee kunkin alustan erityispiirteet automaattisesti, mutta yksityiskohtia asetuksestasi varten:

• Korjaa CloudM-siirron paivamaaarat Gmailissa
• Korjaa CloudM-siirron paivamaaarat Outlookissa
• Korjaa CloudM-siirron paivamaaarat Google Workspacessa
• Korjaa CloudM-siirron paivamaaarat Microsoft 365:ssa

Syvallisemman selityksen siita, miksi tama tapahtuu kaikilla siirtotyokaluilla (ei vain CloudMilla), loydat artikkelista miksi sahkopostit nayttavat vaaria paivia siirron jalkeen.

Siirretty CloudMilla ja kiinni vaarissa paivamaarissa joka sahkopostissa? Suorita ilmainen skannaus nahdaksesi tarkasti kuinka monta viestia on vaikutettu ja mita korjaus maksaa.