Outlook: IMAP-migraation päivämääräongelma selitettynä

Oire, jonka jokainen tunnistaa

Olet juuri viimeistellyt IMAP-migraation Microsoft 365:een tai Google Workspaceen. Maanantaiaamuna tikettejä alkaa sadella: "Kaikissa sähköposteissani on sama päivämäärä", "Historian selaaminen on rikki", "En löydä enää mitään postilaatikostani". Avaat Outlookin, ja siellä se on: tuhansia sähköposteja, joissa lukee viime viikonlopun päivämäärä. Ei se päivä, jolloin viesti lähetettiin. Se päivä, jolloin migraatio tehtiin.

Kyse ei ole Outlook-bugista. Se on suora seuraus IMAP-protokollan toiminnasta ja migraatiotyökalujen tavasta käsitellä viestejä. Mutta ymmärtääkseen miksi, täytyy avata konepelti.

Kolme päivämäärää yhdessä sähköpostissa

Sähköposti on monimutkaisempi kuin miltä se näyttää. Otsikkokenttä, viestin runko, liitetiedostot... ja useita erillisiä aikaleimoja, jotka elävät rinnakkain. (Jos olet koskaan yrittänyt lukea sähköpostin raakoja otsikoita, tiedät, että se ei ole kevyttä iltapäivälukemista.)

Date:-otsikko (RFC 2822)

Tämä on päivämäärä, jonka lähettäjä on kirjoittanut viestiin lähetyshetkellä. RFC 2822 -standardin mukaisesti se näyttää tältä:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Tämä otsikko on kaiverrettu viestin rakenteeseen. Se ei muutu koskaan, ellei joku muokkaa viestin raakasisältöä suoraan. Se on "lähetetty"-päivämäärä tiukassa merkityksessä.

Received:-otsikko (lisätään jokaisessa verkkovaiheessa)

Jokainen palvelin, joka käsittelee sähköpostia sen matkan aikana, lisää Received:-otsikon viestin alkuun omalla aikaleimallaan. Kolmen palvelimen kautta kulkeneessa viestissä on siis kolme Received:-otsikkoa. Uusin on aina ensimmäisenä. Lopputulos näyttää suunnilleen tältä:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Tulos: kun migraatiotyökalu kuten BitTitan MigrationWiz, CloudM, imapsync tai GSMMO siirtää sähköpostin lähdepalvelimelta kohdepalvelimelle, se toimii itsekin kuin "verkkovaihe". Se lisää uuden Received:-otsikon pinon kärkeen, migraation päivämäärällä ja kellonajalla.

IMAP INTERNALDATE

Tämä on kolmas päivämäärä, ja se on ongelman ydin. INTERNALDATE on palvelinpuolen metatieto, joka on tallennettu IMAP-palvelimelle erillään viestin sisällöstä. Se kuvaa päivämäärää, jolloin sähköposti toimitettiin (tai lisättiin) postilaatikkoon. Kun migraatiotyökalu lisää viestin IMAP APPEND -komennolla, se päättää, mikä arvo INTERNALDATElle annetaan. Monessa tapauksessa työkalut käyttävät migraatiohetken aikaa. Ei alkuperäistä päivämäärää.

Siinä kohtaa kaikki menee pieleen.

Miksi Outlook näyttää migraatiopäivämäärän

Outlook käyttää INTERNALDATEa "Vastaanotettu"-sarakkeen näyttämiseen. Se on Outlookin oletustoiminto, ja se on yhdenmukainen IMAP-spesifikaation kanssa: INTERNALDATE on tarkoitettu kuvaamaan vastaanottoaikaa postilaatikossa. Normaalissa tilanteessa (oikea sähköposti, joka saapuu) INTERNALDATE on lähellä Date:-otsikon arvoa. Molemmat ovat linjassa keskenään.

Epäonnistuneen migraation jälkeen kaikkien tuotujen viestien INTERNALDATE osoittaa yön 14.–15. kesäkuuta 2024 (tai migraatiopäivään). Outlook lukee tämän arvon, näyttää sen "Vastaanotettu"-sarakkeessa, ja lopputulos on katastrofaalinen: 45 000 sähköpostia näyttää saapuneen samana iltana.

Tarkemmin sanottuna, ensimmäinen Received:-otsikko (pinon uusin) vaikuttaa myös näyttöön tietyissä konfiguraatioissa. INTERNALDATE on kuitenkin pääasiallinen tekijä Outlookin "Vastaanotettu"-sarakkeelle IMAP-synkronointitilassa.

Outlook-kiertotie: "Lisää Lähetetty-sarake"

Ensimmäinen asia, jonka useimmat IT-adminit tekevät ongelman löydettyään, on etsiä asiakaspuolen kiertotietä. Sellainen on olemassa.

Outlookissa voi muokata kansion sarakenäkymää niin, että "Vastaanotettu"-sarakkeen tilalle (tai rinnalle) lisätään "Päivämäärä"- tai "Lähetetty"-sarake. "Päivämäärä"-sarake lukee suoraan viestin Date:-otsikon, ei INTERNALDATEa. Koska Date:-otsikkoon ei kosketa migraatiossa, alkuperäiset päivämäärät ilmestyvät takaisin näkyviin.

Outlookissa (desktop, Microsoft 365 -versio): napsauta hiiren oikealla painikkeella viestiluettelon sarakeotsikkoa, valitse "Näkymäasetukset", muokkaa sarakkeita poistamalla "Vastaanotettu" ja lisäämällä "Päivämäärä". Tämä on tehtävissä GPO:lla massajakamista varten.

Paperilla tämä ratkaisee visuaalisen ongelman. Käytännössä se on laastari repeämän päällä.

Kiertotien konkreettiset rajoitukset

Mobiili- ja web-asiakasohjelmat

Outlook iOS:ssä, Androidissa ja Outlook Web Appissa (OWA) ei ole samoja mukauttamisvaihtoehtoja. Windows-koneille tekemäsi näkymämuutos ei tallennu sinne. Käyttäjät, jotka lukevat sähköposteja puhelimellaan, näkevät edelleen migraatiopäivämäärän. Keskikokoisessa yrityksessä se on todennäköisesti puolet käyttäjistä.

Hakutoiminto

Outlook-haku käyttää Windows Search -indeksiä (tai Exchange/Microsoft 365 -palvelimen hakuindeksiä). Tämä indeksi rakennetaan INTERNALDATEn perusteella, ei Date:-otsikosta. Jos käyttäjä hakee "tammikuun 2022 sähköposteja", haku palauttaa viestit, joiden INTERNALDATE on tammikuussa 2022. Ei niitä, joiden Date:-otsikko on tammikuussa 2022. Vanhat sähköpostit katoavat päivämääräsuodattimista. Sarakkeen vaihtaminen ei muuta tätä mitenkään.

Sähköpostisäännöt

Outlookin säännöt ("jos sähköposti on vastaanotettu ennen...", "jos sähköposti on vastaanotettu jälkeen...") käyttävät myös INTERNALDATEa. Päivämäärävälihin perustuva lajittelu- tai arkistointisääntö ei toimi oikein migraation jälkeen, jos INTERNALDATEa ei ole korjattu.

Vaatimustenmukaisuus ja eDiscovery

Tämä on ehkä vakavin kohta. Vaatimustenmukaisuus-, lakiarkistointi- ja eDiscovery-työkalut (esimerkiksi Microsoft Purview) käyttävät INTERNALDATEa oikeudellisten kyselyjen päivämääräreferenssinä. Jos organisaatiotasi koskevat säilytysvelvoitteet tai siihen kohdistuu tietopyyntöjä, vääristyneet INTERNALDATEt voivat aiheuttaa todellisia juridisia ongelmia. Tietosuoja-asetuksen (kuten GDPR:n) noudattamisen valvonta edellyttää, että viestit löytyvät oikeilla päivämäärillä. Pyyntö "kaikki sähköpostit tietyltä aikaväliltä" ei tuota oikeita tuloksia.

Kolmannen osapuolen työkalut

CRM-järjestelmät, tikettityökalut, arkistointiohjelmat... kaikki, mikä yhdistää postipalvelimeen IMAP:n tai Microsoft 365/Google Workspace -rajapintojen kautta, lukee INTERNALDATEa. Outlook-näkymän muuttaminen ei korjaa mitään näiden järjestelmien kannalta.

Ainoa oikea ratkaisu: korjaus palvelintasolla

Lähetetty-päivämäärän mukaan lajittelu Outlookissa ei ole ratkaisu. Se on laastari. Oikea korjaus on tehtävä palvelimen metatietojen tasolla, ei asiakasohjelmanäkymässä.

Käytännössä tämä tarkoittaa jokaisen sähköpostin INTERNALDATEn korjaamista niin, että se vastaa alkuperäisen Date:-otsikon päivämäärää. Alkuperäinen Date:-otsikko on aina viestin sisällä (migraatio ei ole poistanut sitä), joten korjaus on mahdollinen. Siellä tieto oikeasta päivämäärästä sijaitsee.

Google Workspacessa Gmail API tarjoaa internalDate-parametrin, jolla metatietoon voidaan vaikuttaa suoraan. Microsoft 365:ssä mekanismi on erilainen, mutta tavoiteltu lopputulos on sama. Tavallisessa IMAP-palvelimessa standardi sallii päivämäärän määrittämisen viestiä lisättäessä.

Käytännössä tämän operaation toteuttaminen kymmenilletuhansille tuotantosähköposteille ilman tietojen menetystä, ilman kaksoiskappaleita, rikkomatta viestiketjuja tai labeleja, käsitellen reunatapaukset (S/MIME-allekirjoitetut viestit, monimutkaiset MIME-rakenteet, RFC 2047 -standardin mukaiset ei-ASCII-koodaukset, suuret liitetiedostot)... se on aivan eri asia. Skripti, joka toimii 50 testitestisähköpostilla, ei kestä 40 000 viestin tuotantopostilaatikossa. Virhe 429 (API-kiintiö ylitetty), yöllisten verkkoaikakatkaisujen hallinta, jo osittain vioittuneet MIME-rakenteet migraation jälkeen... kaikki tämä vaatii vakavaa insinööriosaamista.

Juuri tähän Redate.io on rakennettu. Patentoitu korjausmoottori analysoi jokaisen sähköpostin otsikkoketjun, tunnistaa luotettavan alkuperäisen päivämäärän, ja soveltaa kohdennettua metatietojen korjausta koskematta viestin sisältöön. Jokainen korjattu sähköposti tarkistetaan yksitellen. Alkuperäiset viestit säilytetään varmuuskopiointikansiossa 30 päivän ajan, mikä tekee peruutuksen mahdolliseksi milloin tahansa. Omatekoinen skripti ei tarjoa tätä koskaan.

Migraatiotyökalun tunnistaminen

Ongelma ilmenee samalla tavalla riippumatta migraation lähteestä, mutta yksityiskohdat vaihtelevat käytetyn työkalun mukaan. BitTitan MigrationWiz, CloudM, imapsync ja GSMMO jättävät kukin oman kädenjälkensä injektoimiinsa Received:-otsikoihin. Redate.io:n analyysipipeline ylläpitää satoja tunnettuja migraatiotyökalun allekirjoituksia erottaakseen migraatio-otsikon normaalin verkkovälitysketjun muista otsikosta.

Jos et tiedä, millä työkalulla migraatio on tehty (se voi hyvinkin puuttua tiedoista, varsinkin jos otat haltuun ympäristön edelliseltä MSP:ltä), Redate.io:n ilmainen skannaus tunnistaa ongelmalliset postilaatikot ja antaa arvion korjattavasta volyymista ennen sitoumista mihinkään.

Tietyille tilanteille löytyy yksityiskohtaiset oppaat: imapsync-siirron päivämäärien korjaus Outlookissa, BitTitan-siirron päivämäärien korjaus Outlookissa tai CloudM-siirron päivämäärien korjaus Outlookissa.

Mitä tehdä nyt

Jos luet tätä artikkelia migraation jälkeen, hyvä uutinen on, että alkuperäinen Date:-otsikko on ehjänä jokaisessa sähköpostissasi. Oikea päivämäärä on siellä, jokaisessa viestissä. Ongelma on metatiedoissa, ei sisällössä. Ja metatiedot voidaan korjata.

Voit myös tutustua artikkeliin IMAP INTERNALDATE: miksi päivämäärät hajoavat syventääksesi ymmärrystä ongelman mekaniikasta, tai lukea kattavan oppaan Outlookin vääriin päivämääriin migraation jälkeen saadaksesi yleiskuvan eri tilanteista.

Valmis korjaamaan postilaatikkojesi päivämäärät? Käynnistä ilmainen skannaus Redate.io:ssa tunnistamaan ongelmalliset sähköpostit ja arvioimaan korjattava volyymi ennen mitään toimenpiteitä.