CloudM Migrate: korjaa vääarät sähköpostipäivät

CloudM Migraten päivämääräongelma, josta kukaan ei varoita

CloudM Migrate on valmis. Hallintapaneeli näyttää 100 % valmis, kaikki käyttäjät siirretty, nolla virhettä. Projektin tiketti suljetaan ja siirrytään seuraavaan asiakkaaseen.

Viikon kuluttua IT-johtaja soittaa. "Miksi jokainen sähköposti postilaatikossani näyttää 2. huhtikuuta?"

Ei jotkut sähköpostit. Kaikki. Viisi vuotta asiakaskirjeenvaihtoa, oikeudellisia asiakirjoja, HR-tietueita, ostotilauksia vuodelta 2020, kaikki näyttävät päivämäärän, jolloin CloudM suoritti siirron. Viestit ovat tallella, sisältö on ehjää, liitteet ovat kunnossa. Mutta päivämaäärät ovat väärin joka ikisessä.

Tämä ei ole CloudM-virhe. CloudMin oma tukidokumentaatio myöntää sen avoimesti. Ongelma on siirtotyökalujen viestinsiirtotavan ja kohde-sähköpostipalvelimien saapuvien viestien metatietojen käsittelytavan risteymässä. Mutta tämän tietäminen ei auta asiakastasi, jonka postilaatikosta on tullut mahdoton järjestää kronologisesti.

Miten CloudM todellisuudessa siirtää sähköpostiviestejä

CloudM Migrate yhdistää lähde- ja kohdealustoihin niiden API:en kautta. Google Workspacen tapauksessa tämä tarkoittaa palvelutiliä, jolla on koko verkkotunnuksen kattava delegointi (määritetty Google Admin Consolessa Turvallisuus > API-hallinta -kohdassa). Microsoft 365:n tapauksessa CloudM käyttää joko Exchange Web Services -palvelua tai Microsoft Graph APIa siirtopolusta riippuen.

Kun CloudM lukee viestin lähteestä, se saa täydellisen RFC 2822 -sisällön, mukaan lukien kaikki alkuperäiset otsikot ja viestin rungon. Alkuperäinen Date:-otsikko (se jonka lähettäjän sähköpostipalvelin leimasi sähköpostin lähetyksessä) tulee mukana ehjänä. Samoin kaikki alkuperäiset Received:-otsikot, jotka jäljittävät viestin toimitusreitin.

Ongelma syntyy siinä, kun kopio kirjoitetaan. Kohde säilyttää sen päivämäärän, jonka se saa: Microsoft 365 ja Gmail säilyttävät alkuperäisen päivämäärän, kun kopio sen välittää. Kun se ei sitä tee, kopio saa päivämääräkseen lisäämishetken. Google Workspacessa jokainen Gmail API:n kautta kirjoitettu viesti saa myös tuoreen Received:-otsikon, jonka päivämäärä on lisäämishetki.

Näin yhden näistä sähköposteista otsikot näyttävät edelleen CloudM-siirron jälkeen Microsoft 365:een:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Alkuperäinen Date:-otsikko vuodelta 2019 on yhä tallella, ja niin on myös alkuperäinen Received:-ketju. Mutta Microsoft 365:ssä Outlookin näyttämä saapumispäivä on postilaatikon oma tieto siitä, milloin viesti saapui: jos CloudM ei välittänyt alkuperäistä päivämäärää, tämä tieto on 2. huhtikuuta 2026.

CloudMin "Strip Received Headers" -asetus

CloudM tarjoaa asetuksen tähän ongelmaan. Kohdealustan lisäasetuksissa Message Options -kohdassa on "Strip Received Headers" -kytkin. Kun se on käytöossä, CloudM poistaa Received-otsikot ennen viestin lisäämistä ja korvaa ne yhdellä otsikolla, joka vastaa sähköpostin Date:-otsikkoa.

Kuulostaa ratkaisulta, eikö? Ei aivan.

Ensinnäakin sinun on tiedettävä asetuksesta ennen siirron suorittamista. Useimmat ylläpitäjät löytävät päivämääräongelman siirron valmistumisen jälkeen. Siinä vaiheessa viestit ovat jo kohteessa väärillä päivämäärillä. CloudMin uudelleenajo asetuksen ollessa käytoössä luo vain kaksoiskappaleita, se ei korjaa sitä mikä siellä jo on.

Toiseksi tällä asetuksella on ehdoton rajoitus, kun Google Workspace on kohde. Googlen oma dokumentaatio vahvistaa: Gmail kirjoittaa aina uudelleen Received:-otsikot API:n kautta lisätyissä viesteissä, leimaten ne lisäysajankohdalla. Tämä on alustatasoinen rajoitus, jota CloudM ei voi ohittaa. Jopa "Strip Received Headers" ollessa käytöossä Google Workspace lisää oman Received:-otsikkonsa siirtopäivämäärällä.

Microsoft 365 -kohteissa asetuksella on vähemmän merkitystä: Microsoft 365 säilyttää sen päivämäärän, jonka se saa, niin että näytetyn päivämäärän ratkaisee se, välittääkö CloudM kunkin sähköpostin alkuperäisen päivämäärän.

Mitkä CloudM-siirrot rikkovat päivämaäärät (ja mitkä eivät)

Kaikki CloudM-siirrot eivät tuota vääriä päivämääriä. Lopputulos riippuu lähde-kohdeyhdistelmästä ja CloudMin käyttämästä API-polusta:

• Google Workspace Microsoft 365:een: Päivämäärät saavat kopion päivämäärän. CloudM lukee Gmail API:n kautta ja kirjoittaa Exchangeen.
• Microsoft 365 Google Workspaceen: Päivämaäärät rikkoutuvat. Strip Received Headersin kanssa Googlen API kirjoittaa silti Received-otsikon uudelleen lisäyspäivämäärällä. CloudMin tukidokumentaatio kutsuu tätä "tiukaksi alustarajoitukseksi".
• Google Workspace Google Workspaceen: Päivämäärät: Verkkotunnuksen vaihdot, vuokralaisten yhdistämiset, yritysostofuusiot, jokainen Gmail API:n kautta kirjoitettu viesti saa Received:-otsikon, jonka päivämäärä on siirron ajankohta.
• Paikallinen Exchange Microsoft 365:een: Riippuu kokonaan siitä, minkä päivämäärän CloudM välittää, kulkeeko kopio IMAP:n tai EWS:n kautta.
• IMAP-lähde (yleinen) mihin tahansa kohteeseen: Sama sääntö pätee: kun CloudM yhdistää yleiseen IMAP-palvelimeen lähteenä, kopio näyttää siirron päivämäärän aina, kun alkuperäistä päivämäärää ei välitetä kohteeseen.

Hankala osuus? CloudMin siirtohallintapaneeli ei signaloi mitään tästä. Edistymispalkki täytyy, tilasarake sanoo "Completed", kappalemääarät täsmaäävät. CloudMin näkökulmasta siirto onnistui. Ja teknisesti se onnistuikin. Viestit siirrettiin. Päivämaäärät vain eivät selvinneet matkasta.

CloudM Managed vs. Self-Service: sama päivämääräongelma

CloudM tarjoaa kaksi käyttöönottomallia. SaaS-versio (CloudM Migrate isännöity) toimii kokonaan CloudMin infrastruktuurissa. Itse isännöitu versio antaa ottaa käyttöön ensisijaiset ja toissijaiset siirtopalvelimet omassa verkossasi, Google Cloudissa, Azuressa tai AWS:ssa.

Jotkut MSP:t olettavat, että itse isännöitu vaihtoehto antaa enemmän hallintaa päivämäärien käsittelyyn, koska siirtopalvelimia hallinnoidaan suoraan. Ei anna. Päivämäärän ratkaisee se, mitä siirtomoottori välittää joka viestin mukana, ja tämä moottori on sama, missä tahansa se toimii. Olipa siirtofarmisi CloudMin pilvessä tai omassa Azure-VM:ssäsi, lopputulos päivämäärien osalta on sama.

CloudM tarjoaa myös täysin hallinnoitua "Serviced Migration" -palvelua, jossa heidän tiiminsä hoitaa projektin alusta loppuun. Sama tulos päivämäärien osalta. Tekniikka on identtinen, käytännössä vain eri kädet näppäimistöllä. Oletko koskaan maksanut premium-palvelusta ja saanut silti saman rajoituksen kuin ilmaisessa tasossa? Juuri siltä tämä tuntuu.

Virheellisten Date-otsikoiden komplikaatio

On vielä yksi CloudM-kohtainen käyttäytyminen, joka pahentaa tilannetta. Kun CloudM kohtaa lähdedähköpostin, jonka Date:-otsikko ei noudata RFC 822:ta (virheellinen aikavy6hyke, puuttuva viikonpäivä, ei-standardimuoto), CloudM muokkaa otsikkoa varmistaakseen viestin siirtämisen.

Tämä tarkoittaa, että jotkut sähköpostit menettävät jopa alkuperäisen päivämääräviitteensä. Muokattu Date:-otsikko ei välttämättä vastaa lainkaan todellista lähetyspäivää. CloudMin tukidokumentaatio mainitsee tämän käyttäytymisen kohdassa "Possible Changes to Migrated Items", mutta ei tarkenna mikä muokattu päivä on.

Postilaatikolle, jossa on 12 000 viestiä kahdeksan vuoden ajalta, voi olla satoja sähköposteja, joiden Date-otsikot ovat hieman ei-standardeja (erityisesti viestejä vanhoilta sähköpostipalvelimilta, automatisoiduilta järjestelmiltä tai kansainväiseltä lähettäjiltä, joilla on aikavyöhykkeen muotoiluominaisuuksia). CloudMin muokkauksen ja sellaisen kopion jälkeen, joka ei kanna alkuperäistä päivämäärää, näillä viesteillä on päivämäärät, joilla ei ole mitään yhteistä todellisuuden kanssa.

Miksi manuaaliset korjaukset eivät skaalaudu CloudMin jälkeen

Voisiko tämän korjata itse? Teknisesti alkuperäinen Date:-otsikko on yhä upotettuna useimpiin viesteihin (paitsi niihin, jotka CloudM muokkasi RFC-yhteensopivuutta varten). Jotkut ylläpitäjät ovat yrittäneet kirjoittaa skripteja päivämäärien korjaamiseksi CloudM-siirron jälkeen.

Tässä on tämän lähestymistavan todellisuus. Pitää yhdistää mahdollisesti tuhansiin postilaatikoihin, joissa kussakin on tuhansia viestejä. Jokaisesta sähköpostista pitää jäsentää täydellinen otsikoketju, tunnistaa mitkä Received:-otsikot CloudM tai kohdepalvelin lisäsi, käsitellä reunatapaukset (S/MIME-allekirjoitetut viestit joissa otsikkomuutos rikkoo allekirjoituksen, PGP-salattu sisältö, moniosainen MIME-rakenne sisäkkäisillä rajoilla, RFC 2047 -koodatut ei-ASCII-otsikot japanilaisilta tai korealaisilta lähettäjiltä), ja tehdä kaikki tämä menettämättä yhtään liitettä tai rikkomatta sähköpostiketjutusta.

Skripti joka toimii 50 testisähköpostilla puhtaasta postilaatikosta ei selviä tuotantoympäristöstä, jossa on 40 000 viestiä vuosikymmenen ajalta. Mitä tapahtuu kun vastaan tulee 47 Mt sähköposti kuudella sisäkkäisellä liitteellä? Entä API-nopeusrajoitukset (250 kiintiöyksikköä käyttäjää kohti sekunnissa Googlella, Microsoftin rajoitus noin 10 000 pyyntöä 10 minuutissa)? Mikä on palautussuunnitelmasi kun jotain menee vikaan viestissä numero 8 347?

Ja todellinen kysymys, jonka useimmat ylläpitäjät esittävät vasta kun on liian myöhäistä: miten varmistat, että jokainen korjattu viesti on todellakin ehjä?

Korjaa CloudM-siirron päivämääarät Redate.io:lla

Redate.io yhdistää suoraan kyseisiin postilaatikoihin (Google Workspace, Microsoft 365 tai IMAP) ja skannaa sähköpostit, joiden näytetty päivämäärä ei vastaa niiden alkuperäistä päivämäärää. Skannaus on ilmainen ja kestää muutaman minuutin postilaatikkoa kohti. Se näyttää vaikutettujen viestien tarkan määrän ennen mitään sitoumusta.

Korjaus käyttää Redaten kehittämää otsikoketjun analysointimoottoria, eikä sen tarvitse tietää, millä työkalulla siirto tehtiin. Redate.io suorittaa kohdistetun metatietojen korjauksen muuttamatta viestin sisältöä, säilyttäen liitteet, ketjutuksen, tarrat, kansiot ja digitaaliset allekirjoitukset. Jokainen korjattu viesti käy läpi yksilöllisen varmennuksen, jossa viestin eheys tarkistetaan alkuperäistä vasten ennen prosessin jatkamista.

Alkuperäiset sähköpostit säilytetään näkyvässä Redate.io - Originals -varmuuskopiokansiossa, kunnes poistat ne itse. Jos jotain täytyyy perua, alkuperäiset ovat siellä postilaatikossa, eivät haudattuna johonkin ulkoiseen arkistoon.

MSP:ille jotka käyttivät CloudMia asiakasympäristöissä, Redate.io käsittelee useiden postilaatikoiden korjaukset laajassa mittakaavassa, samalla viestikohtaisella varmennuksella olipa kyseessä 1 tai 500 postilaatikkoa. CloudMin jättämä päivämääräongelma ei tarvitse tulla asiakkaasi sähköpostiympäristön pysyväksi ominaisuudeksi.

Alustakohtaiset oppaat CloudM-siirroille

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

• Korjaa CloudM-siirron päivämääarät Gmailissa
• Korjaa CloudM-siirron päivämaäärät Outlookissa
• Korjaa CloudM-siirron päivämaäärät Google Workspacessa
• Korjaa CloudM-siirron päivämaäärät Microsoft 365:ssa

Syvällisemmän selityksen siitä, miksi tämä tapahtuu kaikilla siirtotyökaluilla (ei vain CloudMilla), löydät artikkelista miksi sähköpostit näyttävät vääriä päiviä siirron jälkeen.

Siirretty CloudMilla ja kiinni vaarissa päivämäärissä joka sähköpostissa? Suorita ilmainen skannaus nähdäksesi tarkasti kuinka monta viestiä on vaikutettu ja mitä korjaus maksaa.