POP-IMAP-siirto: vanhat sähköpostit saivat tämän päivän päivämäärän

Tuttu maanantaiaamun tilanne

Olet juuri vaihtanut sähköpostitilisi POP3:sta IMAP:iin. Konfigurointi sujui mutkattomasti, palveluntarjoajasi opasti sinut läpi prosessin, kaikki tuntui menevän hyvin. Kunnes avasit postilaatikkosi uudelleen. Vuoden 2019 sähköpostit, vuoden 2021 viestit, viime vuoden arkistot... kaikissa näkyy sama päivämäärä: tänään. Joskus jopa sama kellonaika, sekuntien tarkkuudella.

Kyse ei ole sähköpostiohjelmasi bugista. Ei myöskään aikavyöhykeongelma. Tämä on IMAP-protokollan odotettua toimintaa, ja se koskettaa kaikkia, jotka siirtävät paikallisesti tallennettuja sähköposteja palvelimelle tällä tavoin.

POP3 vs IMAP: perustavanlaatuinen ero tallennuksessa

Jotta ymmärtää miksi ongelma syntyy, täytyy ensin ymmärtää miten POP3 toimii ja miten se eroaa radikaalisti IMAP:ista.

POP3:ssa palvelin toimii vain väliaikaisena postilaatikkona. Sähköpostiohjelma (Outlook, Thunderbird, Apple Mail) muodostaa yhteyden, lataa viestit, ja poistaa ne palvelimelta (tai jättää ne paikoilleen asetuksistasi riippuen). Sähköpostit elävät sen jälkeen yksinomaan paikallisesti: Outlookin .pst-tiedostossa, Thunderbirdin paikallisessa profiilissa tai tietokantatiedostossa kovalevylläsi.

IMAP toimii päinvastoin: sähköpostit asuvat palvelimella. Sähköpostiohjelma näyttää vain sen, mitä palvelimella on tallennettuna. Tästä syntyy läpinäkyvä synkronointi kaikkien laitteidesi välille.

Ongelma ilmaantuu siirtymävaiheessa. Kun remontoit vanhat paikalliset POP-sähköpostit IMAP-palvelimelle.

IMAP APPEND: komento joka muuttaa kaiken

Kun sähköpostiohjelma siirtää paikallisen viestin IMAP-palvelimelle, se käyttää komentoa IMAP APPEND. Tämä komento kertoo palvelimelle: "tallenna tämä viesti kyseiseen kansioon".

Palvelin vastaanottaa viestin, tallentaa sen ja antaa sille aikaleiman. Tämä aikaleima on INTERNALDATE. Se on IMAP:in keskeinen metatieto: se kertoo milloin viesti on talletettu palvelimelle. Oletuksena, jos asiakas ei erikseen määritä päivämäärää APPEND-komennossa, palvelin käyttää... nykyhetkeä.

Toisin sanoen: vaikka viestin otsakkeissa lukisi päivämäärä vuodelta 2018, jos kukaan ei kerro palvelimelle "tämä sähköposti on vuodelta 2018", palvelin päättelee sen saapuneen juuri nyt ja antaa sille tämän päivän INTERNALDATE:n.

(Jos olet joskus katsonut sähköpostin raakaotsakkeet, olet nähnyt rivin Date: kymmenen muun Received:-rivin seassa. Tämä RFC 2822:n mukainen Date:-kenttä sisältää todellisen lähetyspäivämäärän. IMAP INTERNALDATE on kuitenkin erillinen metatieto, joka tallennetaan palvelinpuolelle eikä liity itse viestin sisältöön.)

Miksi tämä eroaa IMAP-IMAP-siirrosta

Perinteisessä IMAP-palvelimelta toiselle -siirrossa (BitTitanilla, CloudM:llä, imapsyncillä jne.) ongelma on hieman erilainen. Siirtotyökalu kopioi viestit palvelimelta toiselle, ja tässä tilanteessa se voi periaatteessa välittää alkuperäisen INTERNALDATE:n kohdepalvelimelle APPEND-komennon kautta. Siellä ongelma on se, että jotkin työkalut lisäävät Received:-otsakkeen siirron päivämäärällä, mikä häiritsee näyttämistä Outlookin kaltaisissa ohjelmissa.

Sinun tilanteessasi lähdetään täysin paikallisista tiedoista. Kopioitavaa alkuperäistä INTERNALDATE:a ei yksinkertaisesti ole. .pst-tiedosto tai Thunderbirdin profiili tallentaa viestit omassa suljetussa formaatissaan, omine sisäisine metatietoineen. Kun sähköpostiohjelma lukee näitä viestejä ja siirtää ne IMAP-palvelimelle, se rakentaa APPEND-komennon viestin sisällön perusteella. Useimmiten se ei välitä eksplisiittistä päivämäärää.

Tulos: IMAP-palvelin vastaanottaa satoja tai tuhansia viestejä seuraavien minuuttien aikana ja antaa kaikille saman ajanjakson INTERNALDATE:n: juuri nyt.

Juuri siksi ongelma leviää kaikille laitteillesi välittömästi. Puhelimesi, tablettisi, toinen tietokoneesi: ne kaikki yhdistyvät samalle IMAP-palvelimelle ja näkevät täsmälleen saman asian. Korjaaminen asiakaspuolelta ei onnistu.

Mikä ohjelma näyttää mitäkin, ja miksi

Kaikki sähköpostiohjelmat eivät reagoi samalla tavalla. Tämä on seikka, jonka monet IT-ylläpitäjät huomaavat vasta jälkikäteen.

Outlook (uusimmissa versioissa, erityisesti 2023-2024 päivitysten jälkeen) käyttää palvelimen INTERNALDATE:a "Vastaanotettu"-sarakkeessa. Se näyttää siis siirtopäivämäärän, ei alkuperäistä lähetyspäivää. Tämän Outlook-spesifisen käytöksen ymmärtämiseen tämä artikkeli on hyödyllinen: Outlook: IMAP-migraation päivämääräongelma selitettynä.

Gmail / Google Workspace ja Thunderbird käyttäytyvät hieman eri tavalla. Gmail voi joskus käyttää viestin otsakkeen Date:-kenttää näyttämiseen, mikä antaa vaikutelman että kaikki on hyvin... kunnes yrität lajitella viestilistaa päivämäärän mukaan ja huomaat järjestyksen olevan täysin sekaisin.

Apple Mail näyttää yleensä Date:-otsakkeesta poimitun päivämäärän, mutta lajittelu ja haku käyttävät taustalla INTERNALDATE:a. Sähköpostit voivat siis "näyttää" oikein päivätyiltä visuaalisesti, mutta lajittelutoiminto ei enää toimi kunnolla. Apple Mailin käytöksestä lisää täällä: Apple Mail: väärät päivämäärät migraation jälkeen.

Hyvä uutinen: alkuperäinen päivämäärä on tallessa

Jokaisen sähköpostin Date:-otsake, se joka sisältää todellisen lähetys- tai vastaanottoajan, on koskematon. Se on yhä siellä, itse viestin sisällä. Tämän näet kun avaat sähköpostin ja katsot sen yksityiskohtia.

IMAP-palvelin on "rikkonut" ainoastaan INTERNALDATE:n, tämän viestin ulkoisen metadatan. Viesti itsessään on ehjä.

Tämä tekee korjaamisen mahdolliseksi. Se selittää myös miksi ongelma voi jäädä huomaamatta hetken aikaa: sähköpostit näyttävät oikeilta kun niitä avaa yksitellen. Vasta kun katsoo postilaatikon listanäkymää päivämäärän mukaan lajiteltuna, ongelma paljastuu. Vuoden 2019 sähköpostit ilmestyvät listan kärkeen kuin ne olisi juuri saapuneet. Kaikilla sama päivämäärä.

Mittakaavaongelma: 3000 viestiä on eri asia kuin 3

Ehkä ajattelet: "Poistan vain viestit ja tuon ne uudelleen, tällä kertaa oikein." Viidellä tai kymmenellä testisähköpostilla se toimii. Kahdeksan tuhannen viestin postilaatikossa, jossa on sisäkkäisiä kansioita, suuria liitetiedostoja, S/MIME-allekirjoitettuja viestejä ja vuodelta 2015 alkavia viestiketjuja... se on toinen juttu.

Kotitekoinen skripti, joka toimii 50 viestin testierällä, voi hyvin tuottaa kaksoiskappaleita, kadottaa liitetiedostoja tai rikkoa viestiketjuja tuotantopostilaatikossa. API-kiintiöiden hallinta, verkkoaikakatkaisut, epätavalliset MIME-rakenteet... kaikki ovat reunatapauksia, joita erikoistumaton työkalu ei käsittele.

Entä jos jokin menee pieleen puolivälissä? Ilman varmuuskopio- ja palautusmekanismia tiedot voi menettää ilman mahdollisuutta palauttaa niitä.

Ongelma on hyvin tuttu suurivolyymisia siirtoja hallinnoiville ylläpitäjille. On yksi asia ymmärtää miksi päivämäärät ovat rikki. On aivan toinen asia korjata 15 000 sähköpostin päivämäärät huolellisesti, säilyttäen jokaisen viestirakenteen. Aiheesta lisää artikkelissa Voidaanko päivämäärät korjata migraation jälkeen?, joka käy läpi eri lähestymistapoja ja niiden rajoituksia.

Miten Redate.io käsittelee tämän tilanteen

Redate.io on suunniteltu juuri tätä tilannetta varten. Sen analyysimoottorin tunnistaa sähköpostit, joiden INTERNALDATE ei vastaa viestin otsakkeissa olevaa päivämäärää - oli kyse sitten POP-IMAP-siirrosta, IMAP-palvelimelta toiselle -siirrosta tai paikallisten arkistojen manuaalisesta palautuksesta.

Monivaiheinen analyysipipeline tarkastaa jokaisen viestin otsakeketjun, validoi RFC-yhteensopivuuden ja rekonstruoi päivämäärämetatiedot muuttamatta viestin sisältöä: ei tekstiä, ei liitetiedostoja, ei MIME-rakennetta, ei mahdollisia digitaalisia allekirjoituksia. Jokainen korjattu sähköposti tarkistetaan yksitellen ennen vahvistusta.

Alkuperäiset viestit säilytetään näkyvässä varmuuskopiointikansiossa 30 päivän ajan. Jos jokin ei ole mielesi mukainen, voit palauttaa alkuperäiset.

Alkuskannaaus on ilmainen: Redate.io analysoi postilaatikkosi, tunnistaa ongelmalliset sähköpostit ja kertoo tarkan lukumäärän ennen kuin teet mitään päätöksiä. Ei sokkoon sitoutumista.

Redate.io yhdistää suoraan postilaatikoihin Google Workspacen (domain-delegointi), Microsoft 365:n (Azure AD) tai suoran IMAP:in kautta. Ei paikallista asennusta. Ei .pst-tiedostojen käsin manipulointia.

Useita postilaatikoita hallinnoiville ylläpitäjille, jotka haluavat lisätietoa tällaisista tilanteista, artikkeli MSP: asiakkaiden sähköpostien päivämääräkorjaus on hyvä lisälukemisto. Thunderbirdin erityiskäytöksestä POP/IMAP-siirtymässä lisää täällä: Thunderbird: väärä päivä migraation jälkeen.

Jos siirto on vielä edessä: ennakoi ongelma

Jos et ole vielä siirtänyt paikallisia arkistojasi IMAP-palvelimelle, tai jos organisaatiossasi on tulossa lisää POP-tilisiirtoja, pidä seuraavat asiat mielessä.

• Tarkista tukeeko sähköpostiohjelmasi eksplisiittisen päivämäärän välittämistä APPEND-komennossa. Thunderbird esimerkiksi on käyttäytynyt vaihtelevasti eri versioissa tässä asiassa.
• Tee ensin testi validointitilillä 50-100 edustavalla viestillä: vanhoja sähköposteja, liitetiedostoja sisältäviä viestejä, allekirjoitettuja viestejä. Tarkista näytetyt päivämäärät eri ohjelmissa.
• Suunnittele korjaus ennen kuin loppukäyttäjät alkavat työskennellä siirretyssä postilaatikossa. Päivämäärien korjaaminen aktiivisessa postilaatikossa on monimutkaisempaa kuin tyhjässä post-migraatio-postilaatikossa.
• Dokumentoi sähköpostien määrä ennen siirtoa ja sen jälkeen. Se on ainoa tapa havaita hiljaiset tietohäviöt.

Kattavan tarkistuslistan siirtoa edeltävistä ja sitä seuraavista tarkistuspisteistä löydät artikkelista Sähköpostimigraation tarkistuslista: päivämääräongelmat kuriin.

Vanhat sähköpostisi näyttävät tämän päivän päivämäärää POP-IMAP-siirron jälkeen? Käynnistä ilmainen skannaus Redate.io:ssa mitataksesi ongelman laajuuden ja korjataksesi päivämäärätiedot koskematta viestiesi sisältöön.