Exchange IMAP-tuonti: miksi sähköpostien päivät muuttuvat

Exchange IMAP-tuonnit ja sähköpostiesi päivämäärät

Exchange Online antaa postilaatikon jokaiselle viestille päivämäärän, ja juuri sitä päivämäärää Outlook näyttää ja käyttää lajitteluun. Internetistä saapuvalle sähköpostille se on toimitushetki. Siirrossa kopioidulle sähköpostille se on mikä tahansa päivämäärä, jonka siirto antoi kopiolle: alkuperäinen, kun siirto välittää sen eteenpäin, tuontipäivä, kun se ei tee sitä.

Tästä syntyvät väärät päivämäärät Exchange IMAP-tuonneissa. Exchange Online ei ylikirjoita sille annettua päivämäärää. Mutta kun tuonti ei välitä sähköpostin alkuperäistä päivämäärää, 7 vuotta vanhan viestin kopio saa tuontipäivän, ikään kuin se olisi juuri toimitettu.

Tulos? Tuot 4 000 sähköpostia vanhalta IMAP-palvelimelta Exchange Onlineen, ja sähköpostit näyttävät tuontipäivän oman päivämääränsä sijaan. Vuosien 2018, 2020 ja 2023 sähköpostit, päivättyinä tänään. Käyttäjäsi avaavat Outlookin maanantaiaamuna ja näkevät seinän identtisesti päivättyjä viestejä.

Miten Exchange Admin Centerin siirtovelho toimii

Exchange Admin Center (EAC) sisältää sisäänrakennetun siirtovelhon IMAP-tuonteja varten. Se on graafinen käyttöliittymä, jonka pariin useimmat Exchange-järjestelmänvalvojat tarttuvat ensimmäisenä: mennään kohtaan Vastaanottajat, sitten Siirto, luodaan uusi erä, valitaan "Siirrä Exchange Onlineen", valitaan IMAP lähteeksi, ladataan CSV-tiedosto postilaatikkokytkennöillä ja käynnistetään erä.

Kulisseissa EAC:n siirtovelho käyttää New-MigrationBatch-komentoa, jonka päätepistetyyppi on asetettu IMAP:iin. Exchange muodostaa yhteyden lähde-IMAP-palvelimeen, lukee jokaisen viestin ja kirjoittaa sen kohteena olevaan Exchange Online -postilaatikkoon. Paperilla yksinkertaista.

Mutta tähän järjestelmänvalvojat törmäävät. Microsoft ei dokumentoi, miten siirto asettaa kunkin kopioidun viestin päivämäärän, ja järjestelmänvalvojat kertovat sähköposteista, jotka tulevat ulos synkronoinnin päivämäärällä alkuperäisen vastaanottopäivän sijaan. Outlook, OWA ja kaikki muut tähän postilaatikkoon yhdistetyt asiakasohjelmat käyttävät sitten tätä päivämäärää näyttämiseen ja lajitteluun.

Alkuperäinen Date:-otsikko vuodelta 2019? Yhä siellä, haudattuna viestin otsikkotietoihin. Mutta Exchange ei käytä sitä Saapuneet-kansiosi lajittelujärjestykseen.

Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest ja sama ongelma

Järjestelmänvalvojat, jotka suosivat komentoriviä, kääntyvät usein New-MailboxImportRequest-komennon puoleen PST-tiedostojen tuonnissa, tai New-MigrationBatch-komennon puoleen IMAP-päätepisteillä palvelimelta palvelimelle tehtävissä siirroissa. Odotus on, että PowerShell antaa enemmän hallintaa. Ja niin se antaakin, joissakin asioissa. Ei päivämäärissä.

New-MailboxImportRequest tuo PST-tiedostoja Exchange Online -postilaatikoihin. PST-tiedosto sisältää jokaisen viestin alkuperäiset aikaleimat. Mutta PowerShell-cmdletissa ei ole parametria, joka ohjaisi sitä, minkä päivämäärän kukin tuotu viesti saa. -PreserveDates-lippua ei ole olemassa (ja uskokaa pois, järjestelmänvalvojat ovat etsineet sellaista).

New-MigrationBatch -SourceEndpoint IMAP-päätepisteellä toimii samalla tavalla kuin EAC-velho, vain ilman graafista käyttöliittymää. Sama IMAP-yhteys, sama tulos päivämäärien osalta. Cmdlet tarjoaa parametreja päivämääräväliin suodattamiseen (-StartAfter, -CompleteAfter) ja kansioiden poissulkemiseen, mutta ei mitään, joka ohjaisi sitä, miten Exchange käsittelee saapuvan viestin aikaleimaa.

Tarkkaan ottaen tämä vaikuttaa lähinnä näyttöpäivämäärään ja lajittelujärjestykseen. Viestin sisältö, mukaan lukien alkuperäinen Date-otsikko, saapuu ehjänä. Ainoastaan kopiolle annettu päivämäärä on väärä, ja juuri se on kaiken käyttäjälle näkyvän takana.

Suora IMAP-tuonti vs. kolmannen osapuolen työkalut

Onko merkitystä, käytetäänkö Exchangen omaa IMAP-tuontia vai kolmannen osapuolen työkalua, kuten BitTitan MigrationWiziä tai CloudM:ää? Lyhyt vastaus: päivämääräongelma tapahtuu joka tapauksessa, mutta hieman eri syistä.

Exchangen omassa IMAP-tuonnissa (EAC-velho tai PowerShell) Exchange itse muodostaa yhteyden lähde-IMAP-palvelimeen ja hakee viestit. Se, miten kunkin kopion päivämäärä asetetaan, riippuu Microsoftista, eikä sitä ole dokumentoitu.

Kolmannen osapuolen työkaluilla siirtotyökalu toimii välittäjänä. Se lukee lähteestä, mahdollisesti muuntaa viestiä ja kirjoittaa sen Exchange Onlineen. Kun työkalu kirjoittaa IMAP:in kautta, Exchange Online säilyttää päivämäärän, jonka työkalu välittää: jos työkalu lähettää sähköpostin alkuperäisen päivämäärän, kopio säilyttää sen; jos ei, kopio saa siirron päivämäärän. Jotkin työkalut lisäävät myös oman Received:-otsikkonsa välityksen aikana.

Käytännön ero? Jälkeen jäävät otsikot eivät ole samat työkalusta toiseen, joten korjaus ei voi nojata yhteen kiinteään kuvioon. Taustalla oleva ongelma on identtinen: näytetty päivämäärä ei ole sähköpostin alkuperäinen päivämäärä.

Miksi Exchange Onlinen kuljetussäännöt pahentavat tilannetta

Tässä on jotain, joka yllättää jopa kokeneet Exchange-järjestelmänvalvojat. Exchange Onlinessa on kuljetussääntöjä (nykyään hallintakeskuksessa "postinkulkusäännöt"), jotka voivat laueta tuoduille viesteille. Jos organisaatiollasi on sääntöjä, jotka leimaavat otsikoita, lisäävät vastuuvapauslausekkeita tai muokkaavat viestejä ehtojen perusteella, nämä säännöt voivat käsitellä myös tuotuja sähköposteja.

Tämä tarkoittaa, että vuoden 2020 sähköpostiin saatetaan liittää vastuuvapauslauseke alatunnisteeseen, tai siihen leimataan X-otsikko compliance-säännöllä, jota ei ollut olemassa, kun alkuperäinen sähköposti lähetettiin. Väärä päivämäärä on näkyvin oire, mutta kuljetussäännöt voivat aiheuttaa lisää odottamattomia muutoksia.

Voiko kuljetussäännöt poistaa käytöstä tuonnin ajaksi? Kyllä, tilapäisesti. Mutta useimmat järjestelmänvalvojat eivät ajattele tehdä sitä, koska he eivät odota kuljetusputken käsittelevän siirrettyjä viestejä lainkaan. Siihen mennessä, kun he tajuavat, mitä tapahtui, tuontierä on valmis ja vahinko on tapahtunut.

Mitä väärät päivämäärät tarkoittavat Exchange-ympäristöissä

Exchange-ympäristöt ovat tyypillisesti yritysympäristöjä. Asianajotoimistoja, rahoituslaitoksia, terveydenhuolto-organisaatioita, valtion virastoja. Nämä eivät ole henkilökohtaisia Gmail-tileja, joissa väärä päivämäärä on lievästi ärsyttävää. Nämä ovat postilaatikoita, joissa sähköpostien aikaleimoilla on oikeudellinen ja sääntelyyn liittyvä merkitys.

Exchangen oikeudellinen pidätys säilyttää sähköpostit päivämääräväleihin perustuen. Jos jokainen tuotu sähköposti näyttää tuontipäivän alkuperäisen päivämäärän sijaan, pidätys tallentaa väärän joukon viestejä. eDiscovery-haku "kaikki viestintä tammikuun ja maaliskuun 2022 välillä" ei palauta mitään, koska nämä sähköpostit näyttävät nyt huhtikuuta 2026.

Säilytyskäytännöt kohtaavat saman ongelman. Organisaatio, jolla on 3 vuoden säilytyskäytäntö, saattaa vahingossa poistaa sähköposteja, jotka näyttävät olevan vuodelta 2026 (ja siten "uusia"), vaikka ne ovat todellisuudessa vuodelta 2019 ja pitäisi säilyttää. Tai päinvastoin: sähköpostit, jotka olisi pitänyt poistaa säilytyskäytännön mukaan, jäävät jäljelle, koska niiden näennäinen päivämäärä on tuore.

Yksi tapaus vuoden 2025 lopulta: MSP siirsi noin 200 postilaatikkoa isännöidyltä Exchange-palveluntarjoajalta Microsoft 365:een EAC:n siirtovelholla. Kolme viikkoa myöhemmin asiakkaan compliance-vastaava huomasi, että neljännesvuosittaiset sähköpostien arkistointiraportit näyttivät jokaisen arkistoidun viestin samalla päivämäärällä. Koko sähköpostiarkisto, joka ulottui 5 vuoden taakse, näytti saapuneen yhtenä ja samana marraskuun tiistaina.

Exchange IMAP-tuontipäivämäärien korjaaminen

Alkuperäinen Date:-otsikko säilyy tuonnista ehjänä. Tuonti ei muuta viestin sisällä olevia alkuperäisiä RFC 2822 -otsikoita. Tämä alkuperäinen päivämäärä on korjauksen ankkuripiste.

Redate.io yhdistää Exchange Online -postilaatikkoon (kukin käyttäjä kirjautuu sisään omalla Microsoft-tilillään), tarkistaa viestit, joissa on IMAP-tuonnin aiheuttamia päivämääräpoikkeamia, ja käyttää Redaten kehittämää korjausmoottoria, joka suorittaa RFC-vaatimustenmukaisuuden validoinnin, viestirakenteen säilyttämisen ja kohdennetun metatietojen rekonstruoinnin. Redaten ei tarvitse tietää, mikä työkalu teki tuonnin: se löytää sähköpostit, joiden näytetty päivämäärä ei vastaa niiden alkuperäistä päivämäärää.

Jokainen korjattu viesti varmistetaan yksitellen: sisällön eheys, liitteiden tarkistussummat, kansioon sijoittelu ja keskusteluketjutus. Alkuperäiset säilyvät oman postilaatikkosi näkyvässä varmuuskopiokansiossa, kunnes poistat ne itse. Jos jokin näyttää väärältä, palautus on yhden napsautuksen päässä.

Miksi ei korjata asiaa PowerShell-skriptillä? Koska Received-otsikko-ongelman ymmärtäminen on helppo osa. 8 000 sähköpostin korjaaminen 50 postilaatikossa vahingoittamatta S/MIME-allekirjoitettuja viestejä, rikkomatta sisäkkäisiä MIME-rakenteita, sekoittamatta ei-ASCII-muotoisia RFC 2047 -otsikoita tai menettämättä kansiomäärityksiä, se on vaikea osa. Miten varmistat, että jokainen korjattu viesti tuotantoympäristössä on ehjä, ettei yhtäkään liitettä ole menetetty, ettei mikään keskusteluketju ole rikkoutunut? Skripti, joka toimii 30 viestin testipostilaatikossa, tukehtuu todellisen maailman reunatapauksiin. Se sopimus, jossa on 42 Mt:n liite ja kolme upotettua kuvaa multipart/mixed-rakenteessa multipart/alternative-kääreen sisällä? Onnea matkaan.

Alustakohtaiset oppaat

Päivämääräkorjaus kohdistuu Exchange Online -postilaatikon tasolle, mutta käyttäjät käyttävät sähköpostiaan eri asiakasohjelmien kautta. Kukin niistä näyttää päivämäärät eri tavalla:

• Korjaa Exchange IMAP-tuontipäivämäärät Outlookissa
• Korjaa Exchange IMAP-tuontipäivämäärät OWA:ssa (Outlook verkossa)

Etsitkö laajempaa kontekstia Microsoft 365:n päivämääräongelmiin eri siirtotyökaluilla? Katso täydellinen opas sähköpostien päivämäärien korjaamiseen Microsoft 365 -siirron jälkeen.

Jäivätkö postilaatikkosi väärillä päivämäärillä Exchange IMAP-tuonnin jälkeen? Aloita ilmaisella tarkistuksella nähdäksesi, kuinka monta sähköpostia asia koskee ja mitä korjaus maksaa, luottokorttia ei tarvita.