Sähköpostin päivämäärän muuttaminen: tekniset rajat

Sähköpostissa on kolme "päivämäärää". Ei yhtä.

Kun puhutaan sähköpostin vastaanottopäivämäärän muuttamisesta, useimmat ihmiset kuvittelevat jonkin kentän muokkaamista, kuten tiedoston luontipäivän vaihtamista Windowsissa. Todellisuus on hieman monimutkaisempi. Sähköpostissa kulkee oikeastaan kolme erillistä päivämääräkerrosta, joista jokaisella on omat sääntönsä, omat valvojansa ja omat seurauksensa, jos niihin kajotaan.

Kun ymmärtää nämä kolme kerrosta, ymmärtää myös sen, miksi jotkut korjaukset ovat teknisesti perusteltuja ja toiset joko mahdottomia tai välittömästi havaittavissa väärennöksiksi.

Kerros 1: IMAP INTERNALDATE

INTERNALDATE on palvelimen puolella tallennettu metatieto, joka on itse viestin ulkopuolella. Se ei ole osa sähköpostin sisältöä. IMAP-palvelin määrittää sen, ja useimmat sähköpostiohjelmat käyttävät juuri sitä viestien lajitteluun listauksessa.

Outlook esimerkiksi näyttää viestit oletuksena INTERNALDATE-järjestyksessä. Myös Gmail tekee niin tietyissä tilanteissa. Jos INTERNALDATE on väärä, kaikki sähköpostit näyttävät käyttöliittymässä samalta päivältä, vaikka viestin sisäiset otsikkotiedot sanoisivat muuta.

INTERNALDATE asetetaan sillä hetkellä, kun viesti tallennetaan palvelimelle. IMAP-protokollassa ainoa tapa "muuttaa" sitä on epäsuora: täytyy käyttää APPEND-komentoa tallentaakseen viestistä uuden kopion halutulle päivämäärälle. Erillistä SETINTERNALDATE-komentoa ei ole olemassa. Tällä yksityiskohdalla on merkitystä hetken päästä.

Kerros 2: Date:-otsikko (RFC 2822)

Tämä on viestin raakaotsikoissa oleva Date:-kenttä. Sähköpostiohjelma asettaa sen lähetyshetkellä, ja se kulkee viestin mukana palvelimelta palvelimelle. Se on lähettäjän ilmoittama lähetyspäivämäärä.

(Muuten, jos et ole koskaan katsonut sähköpostin raakaotsikkoja, se on melko outoa luettavaa. Jokaisessa viestissä roikkuu parikymmentä teknistä riviä, joita 99 % ihmisistä ei ole koskaan nähnyt.)

Teknisesti mikään ei estä lähettämästä sähköpostia, jossa Date:-kenttä on takautuva tai tulevaisuuteen asetettu. SMTP-palvelimet eivät validoi tätä kenttää. Mutta vastaanottavat palvelimet kirjaavat todellisen saapumisajan Received:-otsikoihin, mikä luo välittömästi ristiriidan, jonka mikä tahansa sähköpostiohjelma tai analysointityökalu havaitsee.

Kerros 3: pinoutuvat Received:-otsikot

Joka kerta kun SMTP-palvelin välittää viestin, se lisää pinon yläosaan uuden Received:-otsikon aikaleimoineen. Kolmen palvelimen kautta kulkeneessa sähköpostissa on kolme Received:-otsikkoa. Ne luetaan alhaalta ylöspäin: vanhin on alimmaisena, uusin ylimmäisenä.

Juuri tähän migraatiotyökalut luovat ongelman. Kun BitTitan MigrationWiz, CloudM, imapsync tai GSMMO siirtää sähköpostin, se tallentaa sen uudelle palvelimelle IMAP-protokollan kautta. Tämä tallennus luo uuden Received:-merkinnän, johon on aikaleimana migraation päivämäärä. Tulos: postilaatikon vanhin viesti, vuoden 2019 sähköposti, saa Received:-otsikon, joka on päivätty marraskuulle 2024. Ja koska jotkut sähköpostiohjelmat, Outlook erityisesti, käyttävät uusinta Received:-otsikkoa näyttöpäivämääränä...

Siinä ongelma. 15 000 sähköpostia näyttää samaa migraatiopäivämäärää.

Voiko näitä päivämääriä oikeasti "muuttaa"?

Teknisesti kyllä INTERNALDATE:n osalta, tietyin rajoituksin. Teknisesti mahdollinen mutta hyödytön Date::n osalta. Ja Received:-otsikoiden kohdalla asia on syytä penkoa tarkemmin.

Received:-otsikon uudelleenkirjoittaminen on triviaalia. Ja välittömästi havaittavissa.

Received:-otsikko on vain tekstirivi viestin sisällä. Sitä voi muokata kuten mitä tahansa tekstitiedostoa. Se on juuri niin yksinkertaista kuin miltä kuulostaa.

Mutta tässä tulee se, mitä tapahtuu sen jälkeen.

Ensimmäinen ongelma: DKIM. DKIM-allekirjoitus (DomainKeys Identified Mail) lasketaan viestin tietyistä otsikoista, joskus mukaan lukien Received:-otsikot. Allekirjoitetun otsikon muokkaaminen mitätöi allekirjoituksen. Jokainen vastaanottava palvelin, joka tarkistaa DKIM:n, näkee välittömästi, että viestiin on kajottu. Se ei ole hienovarainen väärennös, vaan suoranainen hälytys.

Toinen ongelma: sisäiset tunnisteet. Nykyaikaiset sähköpostipalvelut, kuten Google Workspace ja Microsoft 365, antavat jokaiselle viestille kasvavan ja yksilöllisen sisäisen tunnisteen. Nämä tunnisteet liittyvät INTERNALDATE:en ja vastaanottojärjestykseen. Received:-otsikon muokkaaminen ilman johdonmukaisuutta näiden tunnisteiden kanssa luo ristiriitoja, jotka auditointityökalut havaitsevat vaivatta.

Kolmas ongelma, käytännöllisempi: vaikka muokkaisitkin viestin sisällä olevaa Received:-otsikkoa, INTERNALDATE pysyy ennallaan, eli IMAP-tallennetulla päivämäärällä. Sähköpostiohjelma jatkaa väärän päivän näyttämistä lajittelussa. Olet muokannut viestiä turhaan.

Lyhyesti: Received:-otsikoiden uudelleenkirjoittaminen pahantahtoisessa tarkoituksessa on teknisesti triviaalia, mutta asiantuntija havaitsee sen muutamassa sekunnissa. Se ei ole vakavasti otettava reitti.

Date:-otsikko: menneisyyden muuttaminen paperilla

Sama logiikka pätee Date:-kenttään. Sen voi muokata viestin sisällä. Mutta välittäjäpalvelimien vahvistamat Received:-otsikot pysyvät koskemattomina ja kertovat eri tarinan. Aikajana on ristiriidassa. Kuka tahansa analyytikko tai tuomioistuin, joka vertaa näitä kenttiä, näkee sen välittömästi.

Tarkkaan ottaen se ei estä joitakin sähköpostiohjelmia näyttämästä muokattua Date:-kenttää, jos niille tarjotaan suoraan .eml-tiedosto. Mutta live-sähköpostipalvelimen kontekstissa, autentikoinnin ja lokien kanssa, muokkaus on läpinäkyvää.

IMAP-migraatio: ainoa konteksti, jossa päivämäärien korjaus on perusteltua

On yksi, ja vain yksi tapaus, jossa sähköpostin vastaanottopäivämäärän muuttaminen on paitsi mahdollista myös teknisesti perusteltua: huonosti hallitun IMAP-migraation aiheuttamien vahinkojen korjaaminen.

Tilanne on konkreettinen. Olet juuri siirtänyt 80 Exchange-postilaatikkoa Microsoft 365:een. Migraatio päättyi perjantai-iltana. Maanantaiaamuna ensimmäiset tiketit alkavat tulla: "Kaikissa sähköposteissani on sama päivämäärä", "En löydä viime vuoden sähköpostia", "Asiakasviestihistoriani on täysin rikki." Sinulla on 80 jumissa olevaa käyttäjää ja esimies odottamassa vastausta.

Tässä tilanteessa ongelma on dokumentoitu, tunnistettavissa, ja sen syy on selvä: migraatiotyökalu lisäsi migraatiopäivämäärällä aikaleimoidun Received:-otsikon, ja jotkut sähköpostiohjelmat käyttävät tätä uutta otsikkoa näyttöpäivämääränä. Alkuperäinen Date:-otsikko on kuitenkin ehjänä jokaisessa viestissä. Sitä ei ole koskaan muutettu. Se sisältää edelleen oikean, alkuperäisen lähetyspäivämäärän.

Korjaus ei siis ole väärennös: se on palauttaminen. Lähdetään oikeasta datasta (alkuperäinen Date:) ja rakennetaan johdonmukainen metadata uudelleen. Se on perustavanlaatuisesti erilaista kuin yrittää esittää vuoden 2024 sähköposti vuoden 2019 viestinä.

Kunkin migraatiotyökalun erityisistä mekanismeista löytyy tarkempaa tietoa näistä oppaista: BitTitan-päivämäärien korjaaminen Microsoft 365:ssä, CloudM-päivämäärien korjaaminen Outlookissa tai imapsync-päivämäärien korjaaminen Google Workspacessa.

Miksi oman skriptin kirjoittaminen on riskialtista

Peruslogiikka on ymmärrettävissä. Kuka tahansa IT-ylläpitäjä, joka on viettänyt aikaa IMAP-foorumeilla, voi hahmottaa yleisen lähestymistavan. Se ei ole ongelma.

Ongelma on kuilu sellaisen skriptin välillä, joka toimii 50 testitestisähköpostilla, ja sellaisen, joka pyörii 40 000 tuotantoviestillä menettämättä yhtäkään sähköpostia, turmelematta yhtään liitetiedostoa, ja rikkomatta yhtään viestiketjua.

Muutamia konkreettisia tapauksia, joita kotitekoiset skriptit eivät yleensä hallitse:

• S/MIME-allekirjoitetut sähköpostit: allekirjoitus kattaa sisällön ja otsikot. Viestin rakenteen muuttaminen mitätöi allekirjoituksen. Kömpelösti korjattu allekirjoitettu sähköposti saapuu vastaanottajille "virheellinen allekirjoitus" -merkinnällä.
• PGP-salatut viestit: sama ongelmaperhe, mahdollisesti pahemmilla seurauksilla toteutuksesta riippuen.
• Ei-ASCII-merkistöt otsikoissa: RFC 2047 kuvaa erikoismerkkien enkoodauksen otsikoissa. Skripti, joka manipuloi otsikoita käsittelemättä näitä tapauksia, turmelee äänettömästi sähköpostien aiherivit, joissa on ääkkösiä, japanilaisia merkkejä tai arabialaisia nimiä.
• API-nopeusrajoitukset: Google Workspace ja Microsoft 365 toteuttavat tiukkaa kuristusta. Kello kolme yöllä 10 000 sähköpostin erä, joka törmää 429 Too Many Requests -virheeseen ilman eksponentiaalista backoff-hallintaa, jättää puolet postilaatikoista puoliksi korjatuiksi.
• Vioittuneet MIME-rajat: liitetiedostoja sisältävissä moniosaisissa viesteissä on tarkat MIME-rajat. Niiden virheellinen uudelleengenerointi tekee liitetiedostoista lukukelvottomia.

Ja kysymys, johon mikään kotitekoinen skripti ei vastaa: miten varmistetaan, että jokainen korjattu sähköposti on ehjä? Skripti, joka muokkaa 40 000 viestiä ilman yksilöllistä verifiointia, on arvaus. Arvaus datasta, jonka käyttäjät pitävät usein korvaamattomana.

Artikkeli migraation jälkeen päivämäärien korjaamiseen käytettävistä vaihtoehdoista käy läpi eri lähestymistapoja, myös niiden rajoituksineen.

Mitä Redate.io tekee tässä tilanteessa

Redate.io on suunniteltu nimenomaan tähän tarkoitukseen: IMAP-migraation turmelemien päivämäärien korjaamiseen suuressa mittakaavassa, vaarantamatta viestien eheyttä.

Palvelu yhdistää suoraan kyseessä oleviin postilaatikoihin (Google Workspace toimialueen delegoinnin kautta, Microsoft 365 Azure AD:n kautta tai suoraan IMAP:n kautta), skannaa ilmaiseksi viestit, joissa on väärät päivämäärät, ja soveltaa omaa korjauspipelineaan, joka käsittelee yllä dokumentoidut rajatapaukset. Jokainen sähköposti verifioidaan yksilöllisesti korjauksen jälkeen. Alkuperäiset säilyvät näkyvässä varmuuskopiointikansiossa 30 päivän ajan.

Kuvioiden tunnistus kattaa satoja tunnettujen migraatiotyökalujen allekirjoituksia: BitTitan MigrationWiz, CloudM, imapsync, GSMMO ja niiden variantit. Havaitseminen on tarkkaa: Redate.io ei kajoa sähköposteihin, joiden päivämäärä on oikein.

Hinnoittelumalli on yksinkertainen: kertaluonteinen maksu postilaatikkoa kohden, ilman tilausta. Diagnostiikkaskannaus on ilmainen, joten vahinkojen laajuuden voi arvioida ennen päätöksentekoa.

Jos hallinnoit tästä ongelmasta kärsiviä postilaatikoita, tämä artikkeli Outlookin väärästä päivämäärästä migraation jälkeen käy läpi yleisimmät oireet ja miten ne erottaa muista syistä.

Haluatko mitata ongelman laajuuden omissa postilaatikoissasi? Käynnistä ilmainen skannaus Redate.io:ssa ja näe tarkalleen, kuinka monta sähköpostia on vaikutettu, ennen kuin korjaat mitään.