Vanhat sähköpostit, sama päivämäärä: mitä tapahtui?

Oire: vanhat sähköpostit kasaantuvat samalle päivämäärälle

Avaat Outlookin, Gmailin tai Apple Mailin aamulla. Jokin ei täsmää. Satoja, jopa tuhansia vanhoja sähköposteja näyttää saman päivämäärän: muutaman päivän tai muutaman viikon takaa. Vuoden 2021, 2019 tai 2016 viestit näyttävät saapuneen eilen. Lajittelu päivämäärän mukaan menettää merkityksensä. Haet tärkeää sähköpostia viime vuodelta, ja se hukkuu tuhansien viestien blokkiin, jotka kaikki näyttävät tulleen samana päivänä.

Uudet sähköpostit näyttävät oikeat päivämäärät. Vain vanhat viestit ovat pielessä.

Mitä on tapahtunut?

Ensimmäinen reaktio: syyttää ohjelmistoa

Luontevasti epäillään bugia. Outlook kaatui. Päivitys meni pieleen. Tiedosto on vioittunut. Ja siitä alkaa usein turhauttava etsintä: googletaan "Outlook päivämäärä-bugi", päädytään foorumeille, joissa puhutaan OST-tiedostoista, SCANPST.exe:stä, Outlook-profiilin luomisesta uudelleen...

Kaksi tuntia menee kokeiluihin. Ongelma pysyy.

SCANPST on Outlookin paikallisten datatiedostojen korjaustyökalu. Se voi korjata tiettyjä tiedostovioituksia, mutta ei koske palvelimella oleviin tietoihin. Toisin sanoen, vaikka korjaisit OST-tiedostosi täydellisesti, päivämäärät pysyvät väärissä, koska ongelma ei ole sinun koneessasi.

Ongelma on sähköposteissa itsessään, palvelimella.

Mitä todella tapahtui: migraatio

Lähes poikkeuksetta tämä oire ilmenee sähköpostimigraation jälkeen. Yrityksesi siirtyi vanhasta järjestelmästä Google Workspaceen, Microsoft 365:een tai uudelle palvelimelle. Joku, jossakin, käytti työkalua siirtääkseen kaikki sähköpostisi paikasta toiseen.

Et ehkä saanut siitä tietoa. Tai sait, mutta et yhdistänyt sitä päivämääräongelmaan. Se on täysin ymmärrettävää.

Migraatiotyökalut tekevät valtavan työn: ne kopioivat tuhansia viestejä, kokonaisia kansioita, liitetiedostoja. Mutta niillä on yksi ikävä sivuvaikutus. Kun sähköposti siirretään palvelimelta toiselle, työkalu lisää viestiin pienen teknisen rivin, "Received:"-otsikon, joka kertoo koska viesti saapui uudelle palvelimelle. Eli: migraatiopäivämäärän.

Siinä on ongelman ydin.

Miten sähköpostiohjelma päättää, mikä päivämäärä näytetään

Sähköposti sisältää todellisuudessa useita eri päivämääriä teknisten tietojensa sisällä. On alkuperäinen lähetyspäivä (se jonka normaalisti näet), mutta myös "Received:"-otsikkoja, jotka tallentavat viestin jokaisen välietapin Internetin yli kulkemisessa.

(Jos olet koskaan klikannut "Näytä lähdekoodi" tai "Näytä kaikki otsikot" sähköpostissa, olet ehkä nähnyt nämä kryptisen näköiset rivit, jotka muistuttavat käsittämätöntä tekstiblokkia. Se on juuri se.)

Normaalisti sähköpostiohjelma lukee uusimman "Received:"-otsikon päättääkseen, milloin viesti näytetään. Tämä logiikka toimii täydellisesti: viimeinen "Received:" vastaa aina viestin saapumista postilaatikkoosi, muutamia sekunteja lähetyksen jälkeen.

Migraation jälkeen tämä logiikka kääntyy sinua vastaan. Migraatiotyökalu lisäsi uuden "Received:"-otsikon aivan ylimmäiseksi, siirtopäivämäärällä. Sähköpostiohjelma lukee tämän otsikon ensimmäisenä, näkee migraatiopäivämäärän ja näyttää sen. Alkuperäinen lähetyspäivä on edelleen siellä, koskemattomana, syvemmällä sähköpostin datassa. Mutta ohjelmasi ei näe sitä, koska se pysähtyy ensimmäiseen otsikkoon.

Tulos: 8 000 sähköpostia, jotka kaikki näyttävät saapuneen samana marraskuisena tiistaina.

Mitkä työkalut aiheuttavat tämän ongelman?

Yleisimmillä migraatiotyökaluilla on kaikilla tämä käyttäytyminen. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (Googlen ilmainen työkalu Outlookista siirtymiseen) ja monet muut. Kyse ei varsinaisesti ole niiden virheestä: se on seuraus sähköpostiprotokollan teknisestä toiminnasta. Nämä työkalut lisäävät otsikon, koska protokolla edellyttää sitä, kun viesti siirretään palvelimelta toiselle.

Ongelma on se, että kukaan ei varoita käyttäjiä etukäteen.

Jos yrityksesi on äskettäin vaihtanut sähköpostijärjestelmää, tai jos IT-osasto on suorittanut "pilvimigraation", se on hyvin todennäköisesti ongelman syy. Voit tarkistaa katsomalla vaikuttavia päivämääriä: vastaako niistä suuri osa samaa ajanjaksoa? Jos vastaa, se ajanjakso on migraation ajankohta.

Väärät ratkaisuyritykset, joita kannattaa välttää

Muutamia ratkaisuja, joita foorumeilla usein ehdotetaan, mutta jotka eivät toimi:

Datatiedoston korjaaminen SCANPST:llä

Kuten aiemmin mainittiin: SCANPST korjaa Outlookin paikalliset datatiedostot (.pst- tai .ost-tiedostot tietokoneellasi). Se ei muuta palvelimella olevia sähköposteja. Korjauksen jälkeen sähköposteissa on edelleen samat väärät päivämäärät, koska ne ovat sähköposteissa itsessään, ei paikallisessa tiedostossa.

Outlook-profiilin luominen uudelleen

Sama logiikka pätee. Outlook-profiilin uudelleen luominen tarkoittaa, että aloitat paikallisesti puhtaalta pöydältä ja lataat sitten kaikki sähköpostisi uudelleen palvelimelta. Uudelleen ladatut sähköpostit sisältävät täsmälleen samat väärät päivämäärät kuin ennenkin. Olet vain menettänyt aikaa kaiken uudelleenmääritykseen.

Lajittelu "lähetyspäivän" mukaan vastaanottopäivän sijaan

Jotkut foorumit ehdottavat lajitteluperusteen vaihtamista Outlookissa vastaanottopäivästä lähetyspäivään. Se voi auttaa joissakin tapauksissa... mutta ei aina. Eikä se ratkaise mitään muiden ohjelmistojen, muiden laitteiden tai muiden postilaatikkosi käyttäjien kannalta. Perimmäinen syy on edelleen olemassa. Lajittelu lähetyspäivän mukaan ei ole ratkaisu, se on laastari.

Sähköpostiohjelman uudelleenasennus

Ei. Sähköpostit ovat palvelimella, eivät ohjelmistossa. Outlookin, Gmailin, Apple Mailin tai Thunderbirdin uudelleenasennus ei muuta verkossa tallennettuja tietoja.

Hyvä uutinen: oikeat päivämäärät ovat edelleen tallessa

Tässä on tärkeä asia ymmärtää, ja se tekee korjaamisesta mahdollista: jokaisen sähköpostin alkuperäistä lähetyspäivää ei ole pyyhitty pois. Se on edelleen siellä, sähköpostissa, otsikossa nimeltä "Date:", joka vastaa lähettäjän valitsemaa lähetyspäivää. Se on sähköpostistandardi (määritelty teknisissä spesifikaatioissa nimeltä RFC 2822), jota kaikki migraatiotyökalut noudattavat, koska sen muuttaminen olisi vakava standardien rikkomus.

Toisin sanoen, jos olet saanut sähköpostin 14. maaliskuuta 2022, tämä sähköposti sisältää edelleen kyseisen päivämäärän jossakin datassaan. Se ei vain ole enää se, minkä ohjelmistosi näyttää ensin.

Juuri tämä tekee korjaamisen mahdolliseksi. Kyse ei ole datan menetyksestä. Kyse on metatietojen lukutavasta: sähköpostiohjelmasi lukee väärän päivämäärän, vaikka oikea päivämäärä on edelleen läsnä.

Miksi itse korjaaminen on riskialtista?

Saatat miettiä, voiko IT-ammattilainen yksinkertaisesti kirjoittaa skriptin ongelman korjaamiseksi. Ongelman ymmärtäminen on yksi asia. Sen asianmukainen korjaaminen tuhansille sähköposteille menettämättä yhtään viestiä on aivan eri juttu.

Sähköposti ei ole yksinkertainen tekstitiedosto. Se voi sisältää liitetiedostoja, digitaalisia allekirjoituksia, monimutkaisissa formaateissa koodattua sisältöä. Tällaisen viestin metatietojen muuttaminen rikkomatta sen rakennetta vaatii kymmenien erikoistapausten käsittelyä: sähköisesti allekirjoitetut viestit (S/MIME), salatut sähköpostit (PGP), epästandardit koodaukset, moniosarakenteet... Kotitekoinen skripti, joka toimii 20 testiviestillä, ei todennäköisesti toimi oikein 15 000 viestin tuotantopostilaatikossa. Ja jos jokin menee pieleen, miten varmistetaan, ettei yhtään sähköpostia ole vioittunut tai kadonnut? Kotitekoisella skriptillä: mahdotonta.

Ilman varmuuskopiointi- ja yksilöllistä varmistusmekanismia jokaiselle sähköpostille, sivuvahingon riski on todellinen.

Mitä Redate.io tekee

Redate.io on juuri tätä ongelmaa varten suunniteltu palvelu. Se yhdistää postilaatikkoosi (Google Workspace, Microsoft 365 tai IMAP-palvelin), tunnistaa sähköpostit, joiden päivämäärät on migraation aikana muutettu, ja korjaa ne omalla moottorillaan, joka analysoi koko otsikkoketjun ja rakentaa kunkin viestin päivämäärän metatiedot uudelleen.

Jokainen korjattu sähköposti tarkistetaan yksitellen. Alkuperäiset säilytetään näkyvässä varmuuskopiointikansiossa 30 päivän ajan. Jos jokin menee pieleen, voit palata takaisin.

Alkuperäinen skannaus on ilmainen: Redate.io analysoi postilaatikkosi ja näyttää tarkalleen, kuinka moni sähköposti on vaikuttunut, ennen kuin päätät mitään. Ei yllätyksiä.

Hinnoittelu perustuu kertaluonteiseen maksuun, korjattavien sähköpostien määrän mukaan. Ei tilauksia. Maksat kerran, ongelma on ratkaistu.

Haluatko nähdä vahingon laajuuden ennen sitoutumista? Käynnistä ilmainen skannaus postilaatikostasi Redate.io:ssa ja selvitä muutamassa minuutissa, kuinka monta sähköpostia on vaikuttunut.