Sähköpostin päivämäärän muuttaminen: totta vai tarua?

Kysymys, jonka kaikki esittävät (ja miksi se kätkee kaksi täysin erilaista tilannetta)

Kirjoita Googleen "muuta vastaanotetun sähköpostin päivämäärää". Tuloksena on kymmeniä ketjuja Microsoft Q&A -foorumeilla, Reddit-viestiketjuja, Quora-kysymyksiä. Pyyntö on selkeä, mutta sen takana olevat syyt vaihtelevat radikaalisti sen mukaan, kuka kysyy.

On niitä, jotka haluavat väärentää päivämäärän jälkikäteen syistä, joita mieluummin ei kuvittelisi. Ja sitten on IT-ylläpitäjiä, jotka IMAP-migraation jälkeen näkevät kaikkien sähköpostiensa näyttävän samaa päivää (migraatiopäivää) ja haluavat yksinkertaisesti palauttaa oikeat päivämäärät. Nämä kaksi tilannetta eivät liity toisiinsa millään tavalla, vaikka molemmat johtavat samaan hakuun.

Tämä artikkeli vastaa molempiin. Lyhyesti: ensimmäisessä tapauksessa muutos ei ole käytännössä mahdollinen niin, ettei se jäisi kiinni. Toisessa se on täysin oikeutettua, ja juuri sitä Redate.io tekee.

Ensin: mitä tarkoittaa sähköpostin "päivämäärä"?

Sähköpostissa ei ole yhtä ainoa päivämäärää. Niitä on useita, tallennettuna eri paikkoihin, eri tahojen hallinnoimina.

Date:-otsake (RFC 2822)

Tämä on päivämäärä, jonka lähettäjän sähköpostiohjelma kirjoittaa viestiin lähetyshetkellä. Se näkyy raakaotsakkeiden joukossa muodossa:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Tämä otsake on osa viestin sisältöä. Sitä voi teknisesti muokata, jos pääsee käsiksi raakaan tiedostoon. Mutta "teknisesti" on tässä avainsana.

Received:-otsakkeet

Jokainen sähköpostipalvelin, jonka kautta viesti kulkee, lisää oman Received:-otsakkeensa aikaleimoineen. Nämä otsakkeet muodostavat kronologisen ketjun lähettäjän palvelimelta omaan postilaatikkoosi. (Muuten, jos olet joskus yrittänyt lukea sähköpostin raakaotsakkeita, tiedät ettei se ole kevyttä kesälukemista. Kymmeniä rivejä teknistä metatietoa järjestyksessä, joka kulkee uusimmasta vanhimpaan.)

IMAP INTERNALDATE

Tämä on tärkein metatietokenttä, kun haluaa ymmärtää miksi tietyt muutokset eivät näy missään. INTERNALDATE on IMAP-palvelimen puolelle tallennettu attribuutti, joka on riippumaton viestin sisällöstä. Useimmat sähköpostiohjelmat käyttävät juuri sitä sähköpostien lajitteluun kansioissa. Outlook käyttää sitä. Gmail myös. Apple Mail suurimmassa osassa tapauksia samoin.

INTERNALDATE ei ole viestissä. Se on palvelimen tietokannassa. Sitä ei voi muuttaa muokkaamalla levyllä olevaa .eml-tiedostoa.

Mitä oikeasti tapahtuu, kun muokkaat paikallisesti

.eml-tiedoston muokkaaminen

Teknisesti .eml-tiedosto on tekstitiedosto. Voit avata sen editorissa, muuttaa Date:-riviä ja tallentaa. Jos tuot tiedoston takaisin paikalliseen sähköpostiohjelmaan, näytetty päivämäärä saattaa muuttua ohjelmasta riippuen.

Mutta tässä on se, mikä ei muutu:

• IMAP-palvelimen INTERNALDATE (ennallaan)
• Välipalvelimien lisäämät Received:-otsakkeet
• Googlen, Microsoftin tai muun palveluntarjoajan toimituslokit
• DKIM-allekirjoitus, jos viestissä sellainen oli

Tulos: omalla koneellasi näet ehkä eri päivämäärän. Exchange Onlineen yhdistetyssä Outlookissa tai selaimen Gmailissa mikään ei ole muuttunut.

Järjestelmäkellon muuttaminen

Joillakin foorumeilla ehdotetaan työaseman kellon muuttamista, jotta sähköpostiohjelma "huijautuisi". Se ei toimi. Outlook ja Gmail eivät lue järjestelmäkelloa näyttääkseen vastaanotettujen viestien päivämäärät. Ne lukevat INTERNALDATEn palvelimelta tai viestin otsakkeista. Paikallinen kello ei vaikuta tähän prosessiin lainkaan.

Thunderbird-manipulaatio

Thunderbird tarjoaa enemmän joustoa kuin useimmat ohjelmat. Laajennusten avulla tai suoraan profiilia muokkaamalla (mbox-tiedostot, .msf-tiedostot) jotkut yrittävät muuttaa päivämäärien näyttöä. Se saattaa toimia Thunderbirdissä itsessään, paikallisesti POP3-tilassa tallennetuille viesteille. Mutta heti kun Thunderbird on yhdistetty IMAP-tilassa, se synkronoi palvelimen kanssa. "Korjaus" katoaa seuraavan synkronoinnin yhteydessä.

DKIM: näkymätön este, jota kukaan ei mainitse

Suurin osa vuoden 2018 jälkeen lähetetyistä sähköposteista on allekirjoitettu DKIM:llä (DomainKeys Identified Mail). DKIM-allekirjoitus näyttää otsakkeissa tältä:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Kenttä h= listaa allekirjoituksen kattamat otsakkeet. Yllä olevassa esimerkissä Date on allekirjoitettu. Jos muokkaat viestin Date:-otsaketta, DKIM-tarkistus epäonnistuu. Mikä tahansa sähköpostipalvelin tai rikostekninen analyysityökalu voi havaita muutoksen laskemalla allekirjoituksen uudelleen.

Tämä ei ole täydellinen suoja (pahantahtoinen lähettäjä hallitsee omaa DKIM-avaintaan ja voi allekirjoittaa haluamansa lähetyshetkellä). Mutta jo vastaanotetulle ja allekirjoitetulle sähköpostille Date:-otsakteen muuttaminen jättää havaittavan jäljen.

Palvelinlokit: todellinen totuuden lähde

Vaikka onnistuisit muuttamaan kaikki sähköpostin näkyvät metatiedot (otsakkeet, INTERNALDATE, kaikki), palveluntarjoajat säilyttävät omat lokitiedostonsa.

Google Workspace kirjaa jokaisen viestin Admin Consolen auditointilokeihin. Microsoft 365 tekee saman Purview-vaatimustenmukaisuuskeskuksessa. Nämä lokit sisältävät toimituksen aikaleiman riippumatta siitä, mitä ohjelmissa näkyy. Lakimies, juridinen osasto tai tietoturvatiimi voi hakea nämä tiedot. Outlookissa näkyvä päivämäärä ei ole pätevä todiste oikeudessa tai tietoturva-auditoinnissa.

Tarkemmin sanottuna: edes ylläpitäjä, jolla on pääsy postilaatikkoon toimialueen delegoinnin kautta, ei voi kirjoittaa näitä lokeja jälkikäteen uudelleen. Ne ovat käyttäjien ulottumattomissa, etuoikeutetuistakin huolimatta.

Oikeutettu tapaus: migraation jälkeinen korjaus

Olet juuri siirtänyt 150 postilaatikkoa paikallisesta Exchangesta Microsoft 365:een. Seuraavana maanantaina tikettejä alkaa tulvia: "kaikki vanhat sähköpostini on päivätty viime perjantaille". Migraatiopäivämäärä.

Tämä on hyvin dokumentoitu ongelma, joka on täysin erilainen kuin edellä kuvattu. Kukaan ei tässä yritä väärentää mitään. Alkuperäiset päivämäärät ovat yhä tallessa, ehjinä, jokaisen viestin Date:-otsakkeessa. Ongelma tulee muualta: migraatiotyökalu (BitTitan MigrationWiz, CloudM, imapsync tai jokin muu) on lisännyt ketjun alkuun Received:-otsakeen migraatiopäivämäärällä. Outlook, joka tietyissä yhteyksissä luottaa uusimpiin Received:-otsakkeisiin INTERNALDATEn sijaan, näyttää tämän päivämäärän.

Tässä tapauksessa "korjaus" tarkoittaa yhtenäisyyden palauttamista viestin sisällön (alkuperäinen Date:-otsake, yhä paikallaan) ja palvelimen käsityksen (INTERNALDATE, asetettu migraatiohetkellä) välille. Se ei ole väärentämistä. Se on palauttamista.

Tämä on ongelma, jota huonosti konfiguroidut migraatiot aiheuttavat tuhansille postilaatikoille. Ja juuri sen Redate.io ratkaisee.

Miksi itse tekeminen epäonnistuu mittakaavassa

Ongelman ymmärtäminen on yksi asia. Sen korjaaminen 40 000 sähköpostista 150 postilaatikossa menettämättä yhtä ainoaa viestiä on aivan toinen.

GitHubista tai Stack Overflowsta löytyvät skriptit toimivat 20 testisähköpostin kanssa. Tuotantoympäristössä ne törmäävät ongelmiin, joita skriptin tekijä ei osannut ennakoida:

• S/MIME-allekirjoitetut tai PGP-salatut sähköpostit sisältävät rakenteita, joita ei voi käsitellä kuten tavallisia viestejä
• Epästandardi MIME-rajoja sisältävät multipart-viestit aiheuttavat jäsennysvirheitä
• RFC 2047 -koodatut otsakkeet (ei-ASCII-merkit From:- tai Subject:-kentissä) hajottavat yksinkertaiset jäsentimet
• Googlen ja Microsoftin rajapinnat rajoittavat pyyntöjä (rate limiting): kello kolme yöllä 30 000 sähköpostin eräajon aikana virhe 429 Too Many Requests jää käsittelemättä, skripti pysähtyy, eikä kukaan tiedä missä kohtaa se pysähtyi
• Ei palautumismekanismia: jos viesti vioittuu käsittelyn aikana, takaisin ei ole tietä

Redate.io säilyttää kopion jokaisesta alkuperäisestä sähköpostista näkyvässä varmuuskopiointikansiossa 30 päivän ajan. Jokainen korjaus tarkistetaan erikseen. Analyysipipeline tunnistaa satoja tunnettuja migraatiotyökalujen allekirjoituksia sekä kaikki reuna-tapaukset, joita kotitekoinen skripti ei käsittelisi.

Lisätietoa eri työkalujen erityispiirteistä: BitTitan MigrationWiz ja sähköpostien päivämäärät, tai CloudM Migrate: väärät päivämäärät korjataan.

Mikä muuttuu, mikä ei koskaan muutu

Ero on selvä. Taulukon kolme ensimmäistä riviä kuvaavat pinnallisia tai havaittavia muutoksia. Viimeinen kuvaa oikeutettua metatietojen korjausta, joka on linjassa viestin alkuperäisen sisällön kanssa, kun migraatio on aiheuttanut epäjohdonmukaisuuden.

Jos olet tilanteessa, jota taulukon viimeinen rivi kuvaa, oli migraatio tehty imapsyncillä, BitTitanilla, CloudM:llä tai muulla työkalulla, Redate.io on tehty juuri sitä varten.

Sähköpostisi näyttävät migraatiopäivää oikeiden päivämäärien sijaan? Skannaa postilaatikkosi ilmaiseksi Redate.io:lla ja näe tarkalleen, kuinka monta sähköpostia on viallisia, ennen kuin teet mitään päätöksiä.