Jaettu hosting → Microsoft 365: piilevä päivämääräongelma

Ongelma, josta kukaan ei kertonut sinulle

Olet juuri saanut päätökseen sähköpostin siirron OVH:lta, Infomaniakista, Ionosista tai o2switchistä Microsoft 365:een. EAC:n (Exchange Admin Center) siirtoassistentti pyöri koko yön, kaikki näyttää vihreältä, postilaatikot ovat täynnä. Maanantaiaamuna ensimmäinen tiketti: "Kaikissa vanhoissa sähköposteissani on tämän päivän päivämäärä." Sitten toinen. Sitten kymmenen.

Kyse ei ole Microsoft 365:n bugista. Eikä se ole sattumaa. Se on IMAP-siirron mekaaninen seuraus, ja jaetun hosting-palvelun tapauksessa ongelma on usein kaksi kertaa vakavampi kuin tavallisessa siirrossa. Tässä syy.

Miten IMAP käsittelee päivämääriä (ja missä kohtaa menee pieleen)

Jokaisella IMAP-palvelimelle tallennetulla sähköpostilla on kaksi erillistä päivämäärätyyppiä. Toisaalta on Date:-otsake (RFC 2822:n määrittelemä), joka on osa viestin sisältöä itsessään ja kertoo, milloin viesti on lähetetty tai vastaanotettu. Toisaalta on INTERNALDATE, palvelintason metatieto, joka kertoo milloin viesti on talletettu postilaatikkoon. Juuri tätä arvoa sähköpostiohjelmat kuten Outlook käyttävät oletuksena sähköpostien lajitteluun ja näyttämiseen.

(Muuten, jos olet joskus yrittänyt lukea sähköpostin raakoja otsakkeita EAC:ssa, tiedät että se ei ole kevyttä lukemista. Ennen varsinaiseen sisältöön pääsemistä voi olla helposti kaksikymmentä tai kolmekymmentä otsakeriviiä.)

Kun IMAP-siirtotyökalu siirtää viestin postilaatikosta toiseen, sen täytyy luoda INTERNALDATE uudelleen kohdepalvelimella. Jotkin työkalut tekevät tämän oikein. Monet eivät, tai tekevät sen puutteellisesti. Vastaanottava palvelin puolestaan säilyttää sen, mitä sille annetaan: kun kopiolla on alkuperäinen päivämääränsä, Exchange Online säilyttää sen. Kun päivämäärät menevät väärin, katsottava on työkalu, ei Microsoft 365.

Lopputulos: jokainen siirretty sähköposti näyttää tulleen vastaanotetuksi siirron päivänä. Ei väliä, vaikka se olisi vuodelta 2019.

Kaksivaiheinen vioittuminen: miksi jaettu hosting pahentaa kaiken

Tässä kohtaa tilanne muuttuu todella ongelmalliseksi jaetuilta hosting-palveluilta, kuten OVH:lta, Infomaniakista, Gandilta, Ionosista tai o2switchistä, tehtävissä siirroissa.

Nämä palveluntarjoajat käyttävät yleensä jaettuja Postfix-, Dovecot- tai cPanel-palvelimia vakio-IMAP-konfiguraatioilla. Monet pk-yritykset ovat kerryttäneet niihin sähköposteja vuosien ajan, joskus vuodesta 2010 tai 2012 lähtien. Kun ne päättävät siirtyä Microsoft 365:een, siirto etenee usein kahdessa vaiheessa.

Vaihe 1: ensimmäinen vioittuminen (jo ennen Microsoft 365:tä)

Monissa tapauksissa sähköpostit ovat jo käyneet läpi yhden aiemman siirron. Yritys on vaihtanut jaettua hosting-palvelua yhden tai kaksi kertaa vuosien varrella: esimerkiksi Gandilta OVH:lle 2018, sitten OVH:lta Infomaniakiin 2022. Jokainen IMAP-siirto on voinut nollata alkuperäisen INTERNALDATEn siirtopäivään, jos työkalu ei välittänyt alkuperäistä päivämäärää, ja jotkin työkalut jättävät myös omia siirron otsakkeitaan, joihin on leimattu tämä päivämäärä.

Kun sähköpostit saapuvat Microsoft 365:een, niissä on siis jo arpia. Alkuperäinen Date:-otsake on ehjä (se on osa viestin runkoa, kukaan ei koske siihen), mutta päivämäärän metatieto on jo kerran häiritty.

Vaihe 2: toinen vioittuminen siirtyessä Exchange Onlineen

EAC:n IMAP-siirtotyökalu, tai kolmannen osapuolen työkalu kuten BitTitan MigrationWiz IMAP-tilassa, imee sitten sisäänsä nämä jo vaurioituneet sähköpostit. Jos tämäkään työkalu ei välitä sähköpostin alkuperäistä päivämäärää, Exchange Online kirjaa sähköpostin siirtopäivän alle, ja tämä on se "saapumispäivä", jonka Outlook lopulta näyttää.

Maaliskuussa 2017 lähetetyssä sähköpostissa voi siis olla kaksi kerrosta vääriä päivämääriä: vuoden 2022 siirron jättämät otsakkeet ja vuoden 2024 siirron Microsoft 365:een saapumispäivä. Outlook näyttää 2024. Käyttäjä näkee 2024. Se on väärässä kahdella tasolla.

Tarkennuksena: Outlook määrittää näytettävän päivämäärän Exchange Onlinen tallentaman INTERNALDATEn ja läsnä olevien otsakkeiden yhdistelmän perusteella. Mutta aina kun siirtotyökalu ei välitä alkuperäisiä päivämääriä, siirto Exchange Onlineen lisää uuden virhekerroksen vanhan päälle.

Siirtotyökalut ja palveluntarjoajat: riskialttiit yhdistelmät

Jaetusta hostingista tehdyissä siirroissa toistuvat tietyt yhdistelmät hyvin usein:

• OVH / Infomaniak / Ionos + EAC:n IMAP-työkalu: Microsoftin oma työkalu on kätevä, mutta tunnetusti huono säilyttämään päivämäärät oikein suurivolyymisissä IMAP-siirroissa.
• cPanel (o2switch, LWS jne.) + BitTitan MigrationWiz IMAP-tilassa: MigrationWiz IMAP-tilassa lisää omat siirto-otsakkeensa. Lopputulos on dokumentoitu, muun muassa sivullamme BitTitan-siirron päivämäärien korjaaminen Microsoft 365:ssä.
• Gandi / Mailcow + imapsync: imapsync on tehokas työkalu, mutta sen INTERNALDATEn käsittely riippuu konfiguraatiosta. Ilman sopivaa asetusta päivämäärät eivät säily. Katso myös imapsync: päivät eivät säilyneet.
• Mikä tahansa manuaalinen siirto vetämällä ja pudottamalla Outlookissa: jos joku on kopioinut kokonaisia kansioita tekemällä drag-and-drop kahden Outlookissa konfiguroidun tilin välillä, jokaisen sähköpostin INTERNALDATE on ylikirjoitettu kopioinnin päivämäärällä. Poikkeuksetta.

Yhteinen nimittäjä: kaikki nämä menetelmät johtavat Exchange Onlineen sähköposteilla, joiden Outlookissa näkyvä päivämäärä ei enää vastaa mitään todellista.

Miksi "korjaan itse" on huono idea suuressa mittakaavassa

Ongelman ymmärtäminen on yksi asia. 8 000 sähköpostin korjaaminen 40:ssä Exchange Online -postilaatikossa, monimutkaisten kansiohierarkioiden, S/MIME-allekirjoitettujen viestien, suurten liitetiedostojen ja sisäkkäisten viestiketjujen kanssa, on aivan toinen juttu.

PowerShell-skripti, joka näyttää toimivan kymmenellä testisähköpostilla, voi hiljaisesti epäonnistua viestinumerossa 4237 vioittuneen MIME-rajan tai RFC 2047 -koodatun otsakkeen takia (se =?UTF-8?B?...?=-muoto ei-ASCII-merkeille lähettäjien nimissä). Ilman yksittäistä varmistusmekanismia et tiedä siitä. Sinulla on vain yksi kadonnut sähköposti.

DIY:n konkreettiset riskit tämäntyyppisessä siirrossa:

• Viestien kahdentuminen, jos lisäyslogiikka epäonnistuu kesken prosessin
• Puuttuvat liitetiedostot, jos multipart-rakenne rekonstruoidaan väärin
• Katkenneet viestiketjut Outlookissa (keskustelut perustuvat References:- ja In-Reply-To:-otsakkeisiin, jotka voivat muuttua)
• 429-virheitä (Too Many Requests) Microsoft Graph -rajapinnasta kello 3 yöllä, jotka keskeyttävät käsittelyn ilman rollbackia
• Ei mitään yksinkertaista tapaa varmistaa, että kaikki 8 000 korjausta on tehty oikein

Ja jaetuilta hosting-palveluilta tehtävien siirtojen erityistapauksessa on ylimääräinen vaikeus: sähköposteissa on useita kerroksia ylimääräisiä Received:-otsakkeita, ei vain yksi. Yksinkertainen skripti, joka poistaa "viimeisimmän Received:-otsakkeen", ei riitä. Koko ketju täytyy analysoida, jotta tunnistetaan mikä otsake vastaa mitäkin siirtoa ja mikä edustaa todellista alkuperäistä saapumispäivää.

Mitä Redate.io tekee eri tavalla

Käyttäjä kirjautuu sisään omalla Microsoft-tilillään, ja Redate.io avaa juuri sen postilaatikon kirjautumisen antamilla oikeuksilla, ei Azure-portaalia, ei sovellusta rekisteröitäväksi. Alkuperäinen skannaus on ilmainen: Redate.io tunnistaa kaikki sähköpostit, joiden näytetty päivämäärä ei vastaa todellista päivämäärää, ja antaa tarkan arvion postilaatikkokohtaisesti.

Korjaus perustuu omaan moottoriin, joka analysoi jokaisen viestin otsakeketjun kokonaisuudessaan, toimii käytetystä siirtotyökalusta riippumatta ja rekonstruoi päivämäärän metatiedot oikein, myös silloin kun useita vioittumiskerroksia on päällekkäin. Jokainen korjattu sähköposti tarkastetaan yksitellen. Alkuperäiset säilyvät näkyvässä varmuuskopiokansiossa, kunnes poistat ne itse.

Jaetuilta hosting-palveluilta tehtävissä siirroissa Redate.io:n monivaiheinen analyysiputki käsittelee nimenomaisesti kaksinkertaisen vioittumisen skenaariot: se ei tyydy katsomaan viimeisintä Received:-otsiketta, vaan käy läpi koko historian löytääkseen todellisen alkuperäisen saapumispäivän. Katso myös, miten päivämäärät korjataan Microsoft 365 -siirron jälkeen yleisesti, sekä erityisopas rikkinäisistä IMAP INTERNALDATE -arvoista taustalla olevan mekaniikan ymmärtämiseksi.

Ennen siirtoa tai sen jälkeen: kaksi hetkeä toimia

Kaksi tilannetta, kaksi lähestymistapaa.

Et ole vielä migroinut. Hyvä uutinen: vahinkoja on mahdollista rajoittaa. Jotkin siirtotyökalut (MigrationWiz Exchange-tilassa, CloudM oikeilla asetuksilla) säilyttävät päivämäärät paremmin kuin toiset. Mutta jopa parhaimmassa tapauksessa siirto jaetulta hostingiltä ilman puhdasta historiaa jättää todennäköisesti jälkiä. Suunnittele Redate.io:n käyttö siirron jälkeen, ennen kuin luovutat postilaatikot käyttäjille.

Olet jo migroinut ja tiketit tulevat. Redate.io korjaa olemassa olevat postilaatikot Microsoft 365:ssä riippumatta siitä, kuinka kauan sitten siirto tehtiin. Skannaus antaa tarkan kuvan jokaisen postilaatikon todellisesta tilasta ennen minkäänlaista toimenpidettä. Katso myös sähköpostimigraation tarkistuslista, jotta vastaavat ongelmat voidaan välttää jatkossa.

Siirsitkö sähköpostit OVH:lta, Infomaniakista, Ionosista tai o2switchistä Microsoft 365:een ja päivämäärät ovat väärin? Luo Redate.io-tili skannaa postilaatikot ilmaiseksi ja näe tarkasti vahinkojen laajuus ennen kuin päätät mitään.