Exchange IMAP-tuonti: miksi sahkopostien paivat muuttuvat

Exchangen kuljetusputki ja sahkopostien paivamaarasi

Exchange Onlinessa on kuljetusputki. Jokainen viesti joka saapuu postilaatikkoon, tuli se sitten internetista, siirrettiin kansioiden valilla tai tuotiin IMAP:n kautta, kulkee taman putken lapi. Ja putki tekee mita putket tekevat: se leimaa viestin metatiedoilla. Mukaan lukien uusi Received:-otsikko tanaan paivan paivamaraalla.

Tama on paivamaarakorruption juurisyy Exchange IMAP-tuonneissa. Ei bugi. Ei virheellinen maaritys. Microsoftin tietoinen arkkitehtuuripaatos joka kasittelee jokaisen postilaatikkoon saapuvan viestin "uutena toimituksena", vaikka viesti olisi oikeasti 7 vuotta vanha.

Tulos? Tuot 4 000 sahkopostia vanhalta IMAP-palvelimelta Exchange Onlineen, ja jokainen nayttaa tuontipaivamaaran. Sahkopostit vuosilta 2018, 2020, 2023, kaikki leimattu tanaan paivan paivamaraalla. Kayttajasi avaavat Outlookin maanantaiaamuna ja nakevat seinan identtisesti paivattya viesteja.

Miten EAC:n siirtovelho toimii

Exchange Admin Center (EAC) sisaltaa sisaanrakennetun siirtovelhon IMAP-tuonteja varten. Se on graafinen kayttoliittyma johon useimmat Exchange-yllapitajat tarttuvat ensimmaisena: menee Vastaanottajat-kohtaan, sitten Siirto, luo uuden eran, valitsee "Siirraa Exchange Onlineen", valitsee IMAP lahteeksi, lataa CSV-tiedoston postilaatikkokytkennoineen ja kaynnistaa eran.

Kulisseissa EAC:n siirtovelho luo New-MigrationBatch-komennon paatepisteen tyypilla IMAP. Exchange yhdistaa lahde-IMAP-palvelimeesi, lukee jokaisen viestin ja kirjoittaa sen kohde-Exchange Online -postilaatikkoon. Yksinkertaista paperilla.

Mutta tassa on mita tapahtuu kuljetustasolla. Kun Exchange Online vastaanottaa viestin IMAP-lahteesta, se kasittelee sen saman kuljetusputken kautta joka hoitaa tavallisen sahkopostitoimituksen. Putki lisaa Received:-otsikon nykyisella aikaleimalla. Se asettaa viestin sisaisen toimituspaivamaaran nykyhetkeen. Ja Outlook, OWA ja jokainen muu asiakasohjelmisto joka on yhdistetty tuohon postilaatikkoon kayttaa tatae toimituspaivamaraae nayttamiseen ja lajitteluun.

Alkuperainen Date:-otsikko vuodelta 2019? Yha siella, haudattuna viestiotsikoihin. Mutta Exchange ei kayta sitae lajittelujaerjestykseen saapuneet-kansiossasi.

Received: from source-imap.oldserver.com (10.0.0.5) by
    AM6PR04MB5127.eurprd04.prod.outlook.com (2603:10a6:20b:f3::12)
    with Microsoft SMTP Server; Thu, 2 Apr 2026 08:44:19 +0000
Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest ja sama ongelma

Yllapitajat jotka suosivat komentorivia kaantyvat usein New-MailboxImportRequest-komennon puoleen PST-tiedostojen tuontiin, tai New-MigrationBatch-komennon IMAP-paatepisteilla palvelin-palvelin-siirtoihin. Odotus on etta PowerShell antaa enemman hallintaa. Ja antaakin, joihinkin asioihin. Ei paivamaariin.

New-MailboxImportRequest tuo PST-tiedostoja Exchange Online -postilaatikoihin. PST-tiedosto sisaltaa jokaisen viestin alkuperaiset aikaleimat. Mutta kun Exchange Online kasittelee tuonnin, kuljetusputki leimaa silti jokaisen viestin uudella toimituspaivamaraalla. PowerShell-cmdletissa ei ole parametria taman kayttaytymisen ohittamiseen. -PreserveDates-lippua ei ole olemassa (ja uskokaa, yllapitajat ovat etsineet sellaista).

New-MigrationBatch -SourceEndpoint IMAP-paatepisteella toimii samalla tavalla kuin EAC-velho, vain ilman graafista kayttoliittymaa. Sama IMAP-yhteys, sama kuljetusputkikasittely, sama paivamaarien ylikirjoitus. Cmdlet tarjoaa parametreja paivamaaravaalin suodattamiseen (-StartAfter, -CompleteAfter) ja kansioiden poissulkemiseen, mutta mitaan joka ohjaa miten Exchange kasittelee saapuvan viestin aikaleimaa.

Tarkasti ottaen tama vaikuttaa paaasiassa nayttopaivamaraaan ja lajittelujaerjestykseen. Viestin sisalto, mukaan lukien alkuperainen Date-otsikko, saapuu ehjana. Exchange yksinkertaisesti kaaearii sen omiin kuljetusmetatietoihinsa ja kayttaa niita kaikkeen kayttajalle nakyvaan.

Suora IMAP-tuonti vs. kolmannen osapuolen tyokalut

Onko merkitysta kayttaako Exchangen sisaanrakennettua IMAP-tuontia vai kolmannen osapuolen tyokalua kuten BitTitan MigrationWiz tai CloudM? Lyhyt vastaus: paivamaaraongelma tapahtuu kummassakin tapauksessa, mutta hieman eri syista.

Exchangen sisaanrakennetussa IMAP-tuonnissa (EAC-velho tai PowerShell) Exchange itse yhdistaa lahde-IMAP-palvelimeen ja hakee viestit. Kuljetusputki kasittelee jokaisen viestin saapuessaan. Yksi putki, yksi sarja lisattya otsikoita.

Kolmannen osapuolen tyokaluilla siirtotyokalu toimii valittajana. Se lukee lahteesta, mahdollisesti muuntaa viestin ja kirjoittaa Exchange Onlineen. Exchangen kuljetusputki kasittelee yha saapuvan viestin, mutta kolmannen osapuolen tyokalu on saattanut lisata myos oman Received:-otsikonsa valityksen aikana. Joten voit paatya kahdella kerroksella virheellisia paivamaarametatietoja: yhdella tyokalun kasittelysta ja yhdella Exchangen kuljetusputkesta.

Kaytannoen ero? Kun korjaat paivamaaria Exchangen sisaanrakennetun IMAP-tuonnin jalkeen, on tyypillisesti yksi siirto-Received:-otsikko kasiteltavana. Kolmannen osapuolen tyokalulla tehdyn siirron jalkeen Exchangeen niita voi olla kaksi tai kolme. Taustalla oleva ongelma on identtinen, mutta otsikkoketju on sotkuisempi.

Miksi Exchange Onlinen kuljetussaannot paahentavat asiaa

Tassa on jotain joka yllattaa jopa kokeneet Exchange-yllapitajat. Exchange Onlinessa on kuljetussaantoeja (nyt nimelta "postinkulkusaannot" hallintakeskuksessa) jotka voivat laueta tuoduille viesteille. Jos organisaatiollasi on saantoeja jotka lisaavat otsikoita, vastuuvapauslausekkeita tai muokkaavat viesteja ehtojen perusteella, naemae saannot voivat kasitella myoes tuotuja sahkoposteja.

Tama tarkoittaa etta vuoden 2020 sahkoposti ei ehkae saa pelkastaen uutta Received-otsikkoa tanaan paivan paivamaraalla, vaan myos vastuuvapauslausekkeen liitteeksi, tai X-otsikon joka on leimattu compliance-saannoella jota ei ollut olemassa kun alkuperainen sahkoposti lahetettiin. Paivamaarakorruptio on nakyvin oire, mutta kuljetussaannot voivat luoda ylimaaraisia odottamattomia muutoksia.

Voiko kuljetussaannot poistaa kaytosta tuonnin ajaksi? Kylla, tilapaisesti. Mutta useimmat yllapitajat eivat ajattele sitae koska he eivat odota kuljetusputken kasittelevan siirrettya viesteja. Kun he tajuavat mita tapahtui, tuontiera on valmis ja vahinko tehty.

Mita vaaraet paivamaarat tarkoittavat Exchange-ymparistoissa

Exchange-ymparistot ovat yleensa yritysymparistoja. Asianajotoimistoja, rahoituslaitoksia, terveydenhuolto-organisaatioita, valtion virastoja. Nama eivat ole henkilokohtaisia Gmail-tileja joissa vaara paivamaara on lievaesti aersyttaevaa. Nama ovat postilaatikoita joissa sahkopostien aikaleimoilla on oikeudellinen ja saantelyyn liittyva merkitys.

Oikeudellinen pidatys Exchangessa sailyttaa sahkopostit paivamaaravaalien perusteella. Jos jokainen tuotu sahkoposti nayttaa tuontipaivamaaran alkuperaisen paivamaaran sijaan, pidatys tallentaa vaaraen joukon viesteja. eDiscovery-haku "kaikki viestinta tammi-maaliskuussa 2022" ei palauta mitaan koska naemae sahkopostit nayttavat nyt huhtikuuta 2026.

Sailytyskaaytaennoet kohtaavat saman ongelman. Organisaatio jolla on 3 vuoden sailytyskaytanto saattaisi vahingossa poistaa sahkoposteja jotka naeyttaevat olevan vuodelta 2026 (ja siten "uusia") vaikka ne ovat oikeasti vuodelta 2019 ja pitaisi sailyttaa.

Skenaario vuoden 2025 lopulta: MSP siirsi noin 200 postilaatikkoa isannoidylta Exchange-palveluntarjoajalta Microsoft 365:een EAC:n siirtovelholla. Kolme viikkoa myoehemmin asiakkaan compliance-vastaava huomasi etta neljanneasvuosittaiset sahkopostiarkistointiraportit nayttivat jokaisen arkistoidun viestin samalla paivamaraalla. Koko sahkopostiarkisto, joka kattoi 5 vuotta, naytti saapuneen yhtenaa ainoana marraskuun tiistaina.

Korjaa Exchange IMAP-tuontipaivamaarat

Alkuperainen Date:-otsikko selviaa Exchangen kuljetusputkesta vahingoittumattomana. Microsoftin putki lisaa metatietoja viestin ympaerille mutta ei muuta alkuperaisia RFC 2822 -otsikoita sen sisalla. Tuo alkuperainen paivamaara on ankkuripiste korjaukselle.

Redate.io yhdistaa Exchange Online -postilaatikkoon (Microsoft 365 -yllaepitaejaen valtuuttaman paasyn kautta), skannaa viestit joissa on IMAP-tuonnin aiheuttamia paivamaarapoikkeamia ja kayttaa patantoitua korjausmoottoria joka suorittaa RFC-vaatimustenmukaisuuden validoinnin, viestirakentaan sailyttamisen ja kohdennetun metatietojen rekonstruoinnin. Moottori tunnistaa Exchange-kohtaiset kuljetusputkiallekirjoitukset Received-otsikkoketjussa ja erottaa tuontiartefaktit laillisista toimitusotsikoista.

Jokainen korjattu viesti varmistetaan yksiloellisesti: sisallon eheys, liitteiden tarkistussummat, kansioon sijoittelu ja keskusteluketjutus. Alkuperaiset sailyvat nakyvassa varmuuskopioansiossa 30 paivan ajan. Jos jokin nayttaa vaaralta, palautus on yhden napsautuksen paassa.

Miksi ei korjata PowerShell-skriptilla? Koska Received-otsikko-ongelman ymmartaminen on helppo osa. 8 000 sahkopostin korjaaminen 50 postilaatikossa rikkomatta S/MIME-allekirjoitettuja viesteja, vahingoittamatta sisakkaeisia MIME-rakenteita, tuhoamatta ei-ASCII RFC 2047 -otsikoita tai menettamatta kansiomaarityksia, kaytannossa, se on vaikea osa. Miten varmistat etta jokainen korjattu viesti tuotantoymparistossa on ehjae? Skripti joka toimii testipostilaatikossa 30 viestilla ei selvia todellisen maailman reunatapauksista. Se sopimus jossa on 42 Mt liite ja kolme upotettu kuvaa multipart/mixed-rakenteessa multipart/alternative-kaaereen sisalla? Onnea matkaan.

Alustakohtaiset oppaat

Paivamaarakorjaus kohdistuu Exchange Online -postilaatikkotasolle, mutta kayttajat kayvaet sahkopostinsa laapi eri asiakasohjelmilla. Kukin nayttaa paivamaarat eri tavalla:

• Korjaa Exchange IMAP-tuontipaivamaarat Outlookissa
• Korjaa Exchange IMAP-tuontipaivamaarat OWA:ssa (Outlook verkossa)

Etsitkoe laajempaa kontekstia Microsoft 365 -paivamaaraongelmista eri siirtotyokaluilla? Katso taydellinen opas sahkopostien paivamaarien korjaamiseen Microsoft 365 -siirron jalkeen.

Exchange IMAP-tuonti jaetti postilaatikkosi vaarilla paivamaarilla? Aloita ilmaisella skannauksella nahdaksesi kuinka monta sahkopostia on vaikutuksen alaisia ja mita korjaus maksaa, ei luottokorttia tarvita.