Ongelma - kaikki sähköpostit näyttävät saman päivämäärän
IMAP-migraation jälkeen käyttäjät avaavat postilaatikkonsa ja huomaavat hälytttävän tilanteen: jokainen sähköposti näyttää täsmälleen saman päivämäärän. Alkuperäisen lähetys- tai vastaanottopäivämäärän sijaan jokaisessa viestissä lukee migraation suorituspäivä. Vuosien kirjeenvaihto näyttää saapuneen samana päivänä.
Tämä on painajainen IT-ylläpitäjille. Tukipyyntöjä tulee vyörynä, käyttäjät eivät löydä mitään päivämäärän perusteella, ja postilaatikon aikajärjestys on käytännössä tuhoutunut.
Miltä se näyttää Outlookissa
Microsoft Outlookissa "Vastaanotettu"-sarake näyttää migraatiopäivämäärän jokaiselle sähköpostille. Olipa viesti lähetetty 2018 tai 2023, Outlook näyttää saman päivämäärän, sen jolloin migraatioityökalu käsitteli postilaatikon. Saapuneet, Lähetetyt, jokainen kansio on vaikuttunut. Päivämäärälajitteluun luottavien käyttäjien työnkulku on täysin rikki.
Miltä se näyttää Apple Mailissa
Apple Mail macOS:llä ja iOS:llä käyttäytyy samankaltaisesti. Jokaisen viestin vieressä näkyvä päivämäärä heijastaa migraation aikaleimaa alkuperäisen päivämäärän sijaan. Koska Apple Mail käyttää IMAP-palvelimen metatietoja päivämäärien määrittämiseen, sama taustalla oleva ongelma tuottaa saman näkyvän tuloksen. Saapuneet-kansiota selatessa näkee vain seinän identtisiä päivämääriä.
Miltä se näyttää Gmailin verkkokäyttöliittymässä
Gmailin verkkokäyttöliittymässä tilanne on hieman erilainen. Gmailin verkkoliittymä käyttää yleensä sähköpostin omaa "Date"-otsakekenttää, joten viestit voivat näkyä oikealla päivämäärällä Gmailissa. Mutta IMAP INTERNALDATE on silti väärä, mikä tarkoittaa että jokainen IMAP-asiakas joka yhdistää tähän Gmail-tiliin (Outlook, Thunderbird, Apple Mail) näyttää migraatiopäivämäärän. Sama postilaatikko näyttää siis oikealta yhdessä asiakasohjelmassa mutta väärältä toisessa. Aika hämmentävää.
Miksi näin tapahtuu - tekninen syy
Perimminen syy piilee tavassa, jolla IMAP-migraatiotyökalut käsittelevät sähköpostien otsakekentitä ja tavassa, jolla sähköpostiohjelmat päättävät mitä päivämäärää näyttää. Tämän ymmärtäminen vaatii lyhyen katsauksen IMAP-protokollaan ja otsakekenttienn rakenteeseen.
Miten IMAP-migraatioityökalut käsittelevät otsakekentitä
Kun sähköposti siirretään palvelimelta toiselle, migraatiotyökalu lataa raakaviestin lähdepalvelimelta ja lataa sen kohdepalvelimelle IMAP APPEND -komennolla. Tämän prosessin aikana IMAP-protokolla vaatii kohdepalvelinta lisäämään viestiin "Received"-otsakkeen. Tämä otsake sisältää aikaleiman hetkestä jolloin viesti lisättiin uuteen palvelimeen, eli migraatiopäivämäärän.
"Received"-otsake joka rikkoo kaiken
Sähköpostiviestit sisältävät tyypillisesti useita "Received"-otsakekentitä, joista jokaisen on lisännyt viestinä käsitellyt sähköpostipalvelin alkuperäisen toimituksen aikana. Outlook ja muut asiakasohjelmat määrittävät "vastaanottopäivämäärän" lukemalla uusimman "Received"-otsakkeen, sen joka on ketjussa ylimmäisenä. Kun migraatiotyökalu lisää uuden "Received"-otsakkeen migraation aikaleimalla, siitä tulee uusin, ja sähköpostiohjelmat näyttävät tämän päivämäärän alkuperäisen sijaan.
Tämä ei ole migraatiotyökalun tai sähköpostiohjelman bugi. Molemmat noudattavat IMAP- ja sähköpostistandardeja oikein. Ongelma johtuu siitä, että näitä standardeja ei koskaan suunniteltu massasiirtoja varten, ja IMAP APPEND:in sekä päivämääränäyttölogiikan vuorovaikutus tuottaa tämän ei-toivotun tuloksen.
INTERNALDATE vs Date-otsake
IMAP-palvelimet tallentavat kaksi eri päivämääräarvoa jokaiselle viestille. "Date"-otsake on osa itse sähköpostiviestinä, se tallentaa milloin viesti alun perin kirjoitettiin ja lähetettiin. INTERNALDATE on IMAP-palvelimen tallentama metatieto, joka edustaa milloin viesti toimitettiin tai lisättiin kyseiselle palvelimelle.
Jotkut migraatiotyökalut yrittävät säilyttää alkuperäisen INTERNALDATE:n asettamalla sen APPEND-komennon aikana. Mutta vaikka INTERNALDATE olisi oikein asetettu, lisätty "Received"-otsake aiheuttaa silti ongelmia asiakkaissa jotka priorisoivat "Received"-päivämäärää INTERNALDATE:n edelle.
Mitkä migraatiotyökalut aiheuttavat tämän ongelman?
Lähes kaikki IMAP-migraatiotyökalut voivat aiheuttaa tämän ongelman. Ongelma on IMAP-protokollan ominaisuus, ei mihinkään tiettyyn työkaluun sidottu. Joitakin työkaluja tosin yhdistetään ongelmaan useammin niiden laajan käytön vuoksi.
BitTitan MigrationWiz
BitTitan MigrationWiz on yksi suosituimmista kaupallisista migraatiotyökaluista MSP:iden ja IT-konsulttien keskuudessa. MigrationWiz lisää "Received"-otsakkeen joka sisältää "mx.migrationwiz.com" migraatioprosessin aikana. Tästä otsakkeesta tulee ketjun uusin, mikä aiheuttaa migraatiopäivämäärän näkymisen Outlookissa ja muissa IMAP-asiakasohjelmissa. Katso yksityiskohtaiset oppaat: BitTitan-päivämäärien korjaus Outlookissa, Microsoft 365, Google Workspace ja Exchange Online.
CloudM Migrate
CloudM Migrate (aiemmin Cloud Migrator) on laajalti käytössä Google Workspace -migraatioissa. Kuten muutkin työkalut, CloudM lisää oman "Received"-otsakkeensa IMAP-lisäyksen yhteydessä. CloudM:llä siirretyt sähköpostit näyttävät migraatiopäivämäärän "Received"-otsakeeseen perustuvissa asiakkaissa. Katso oppaat: CloudM-päivämäärien korjaus Gmailissa, Outlook, Google Workspace ja Microsoft 365.
imapsync
imapsync on suosittu avoimen lähdekoodin työkalu Linux-ylläpitäjien ja hosting-palveluntarjoajien keskuudessa. Vaikka imapsync yrittää säilyttää INTERNALDATE:n, kohdepalvelin lisää silti "Received"-otsakkeen APPEND-operaation aikana. imapsyncin FAQ tunnustaa tämän rajoituksen mutta ei tarjoa sisäänrakennettua ratkaisua migraation jälkeen lisätyn otsakkeen poistamiseen. Katso oppaat: imapsync-päivämäärien korjaus Outlookissa, Gmail, Microsoft 365 ja Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) on Googlen oma työkalu siirtymiseen Exchangesta tai Outlook PST -tiedostoista Google Workspaceen. GSMMO voi tuottaa saman päivämääräongelman erityisesti kun migraatioon liittyy välivaiheena IMAP-siirto. Katso oppaat: GSMMO-päivämäärien korjaus Outlookissa, Gmail ja Apple Mail.
Exchange Admin Center (natiivi IMAP-tuonti)
Microsoftin Exchange-hallintakeskus sisältää natiivin IMAP-tuontitoiminnon siirtymiseen Exchange Onlineen (Microsoft 365). Tämä sisäänrakennettu migraatiotyökalu lisää "Received"-otsakkeita tuonnin aikana aiheuttaen saman päivämääränäyttöongelman. Katso oppaat: Exchange IMAP -migraatiopäivämäärien korjaus Outlookissa ja OWA.
Manuaalinen IMAP-kopiointi
Jopa sähköpostien manuaalinen kopiointi IMAP-palvelimien välillä esimerkiksi Thunderbirdin avulla voi tuottaa tämän päivämääräongelman. Kun sähköpostiohjelma kopioi viestin IMAP:n kautta, kohdepalvelin käsittelee sen uutena lisäyksenä ja lisää oman "Received"-otsakkeensa nykyisellä aikaleimalla. Katso oppaat: manuaalisen IMAP-kopioinnin päivämäärien korjaus Outlookissa, Gmail, Thunderbird ja Apple Mail.
Miksi yleiset kiertotiet eivät toimi
Tämän ongelman edessä käyttäjät ja ylläpitäjät kokeilevat yleensä useita lähestymistapoja ennen kuin tajuavat ettei mikään niistä oikeasti ratkaise ongelmaa.
"Lajittele lähetyspäivämäärän mukaan" - miksi se ei riitä
Yleisin ehdotus on vaihtaa "vastaanotettu"-päivämäärän mukaisesta lajittelusta "lähetetty"-päivämäärään sähköpostiohjelmassa. Tämä muuttaa näyttöjärjestystä, mutta ei korjaa taustalla olevia tietoja. Hakutulokset näyttävät edelleen väärän päivämäärän. Kalenteriintegraatiot, vaatimustenmukaisuustyökalut ja automatisoidut työkulut jotka perustuvat vastaanottopäivämäärään toimivat edelleen väärin. Ja käyttäjien on muistettava vaihtaa tämä asetus jokaisella laitteella ja jokaisessa kansiossa.
Uudelleenmigraatio - kallis ja riskialtäs
Jotkut ylläpitäjät harkitsevat migraation uudelleen ajamista toivoen välttävänsä päivämääräongelman toisella kerralla. Tämä lähestymistapa on kallis (500-5 000 EUR postilaatikoiden määrästä riippuen), aikaa vievä ja riskialtis. Toinen migraatio aiheuttaa saman "Received"-otsakekeon ongelman, tuplaa tietojen menettämisriskin ja vaatii merkittävän käyttökatkon. Uudelleenmigraatio ei ratkaise päivämääräongelmaa ellei migraatiotyökalua ole perustavanlaatuisesti muutettu.
Otsakkeiden manuaalinen muokkaus - vaatii palvelinpääsyn
Teknisesti korjaus tarkoittaa migraation "Received"-otsakkeen poistamista jokaisesta sähköpostista. Mutta tämän tekeminen manuaalisesti vaatii suoran palvelinpääsyn, sähköpostin otsakekentien rakenteen tuntemusta ja räätälöityä skriptejä. 10 000 sähköpostin postilaatikossa manuaalinen muokkaus on epäkäytännöllistä ja vaarallisen virhealtista. S/MIME-allekirjoitetut sähköpostit, PGP-salatut viestit, multipart-rakenteet sisäkkäisillä MIME-rajoilla, Content-Transfer-Encoding-ongelmat, ei-ASCII-otsakekentät (RFC 2047), ylisuuret liitteet: jokainen näistä tapauksista voi saada yksinkertaisen skriptin korruptoimaan tietoja peruuttamattomasti. Miten varmistetaan että 10 000 korjattua sähköpostia ovat kaikki ehjiä? Ei mitään muuta keinoa kuin erityisesti sitä varten suunniteltu varmennusjärjestelmä.
Oikea ratkaisu - alkuperäisten päivämäärien palauttaminen
Oikea lähestymistapa on tunnistaa migraatioartefaktit jokaisen sähköpostin otsakeketjusta ja tehdä kohdennettuja korjauksia jotka palauttavat alkuperäisen aikajärjestyksen kaikkiin sähköpostiohjelmiin. Tämä ei ole pelkkä otsakkeen muokkausta. Prosessi sisältää RFC-vaatimustenmukaisuuden validoinnin, viestin rakenteen säilyttämisen ja migraatiotunnisteiden vertailun tietokantaan tunnetuista työkaluprofiileista.
Miten Redate.io korjaa tämän ongelman
Redate.io yhdistää postilaatikkoon (Google Workspace, Microsoft 365 tai mikä tahansa IMAP-palvelin) ja analysoi jokaisen sähköpostin tunnistaakseen migraatio-otsakkeista kärsivät viestit. Analyysi on ilmainen ja näyttää tarkalleen kuinka monta sähköpostia on vaikuttunut ennen mitään maksua.
Jokaisen vaikuttuneen sähköpostin kohdalla Redate.io:n oma korjausmoottori ajaa viestin monivaiheisen analyysiprosessin läpi. Moottori vertaa tunnisteita satoihin tunnettuihin migraatiotyökaluprofiileihin, jotka on rakennettu suurten sähköpostimäärien käsittelyn pohjalta. Se käsittelee merkistökoodausongelmat, multipart-rakenteet, upotetut liitteet ja kymmeniä erikoistapauksia jotka saisivat itsetehdyn skriptin korruptoimaan tietoja (ei sen tyyppinen löytö jonka haluaa tehdä maanantaiaamuna). Jokainen korjattu sähköposti käy läpi eheystarkistuksen ennen lopullista vahvistusta. Alkuperäinen viesti siirretään näkyvään "Redate.io - Originals" -kansioon (ei poisteta) ja säilytetään 30 päivää.
Tulos? Sähköpostit näyttävät alkuperäiset oikeat päivämääränsä kaikissa asiakasohjelmissa. Lajittelu toimii jälleen. Postilaatikon aikajärjestys on palautettu.
Usein kysytyt kysymykset
Voidaanko päivämäärät korjata kuukausia migraation jälkeen?
Kyllä. Alkuperäinen "Date"-otsake säilyy sähköpostiviestin sisällä riippumatta migraation ajankohdasta. Redate.io voi korjata sähköpostien päivämäärät viikkoja, kuukausia tai jopa vuosia migraation jälkeen. Korjaus toimii niin kauan kuin sähköpostin alkuperäiset otsakekentät ovat ehjiä.
Poistaako korjaus sähköpostejani?
Ei. Redate.io ei koskaan poista sähköposteja. Alkuperäiset viestit siirretään näkyvään kansioon nimeltä "Redate.io - Originals" postilaatikossa, missä ne pysyvät saatavilla 30 päivää. Jokainen korjattu sähköposti varmennetaan alkuperäistä vasten ennen prosessin viimeistelyä. Jos varmennus epäonnistuu minkä tahansa viestin kohdalla, alkuperäinen pysyy koskemattomana.
Toimiiko tämä jaetuissa postilaatikoissa?
Kyllä. Redate.io toimii jaettujen postilaatikoiden kanssa Google Workspacessa ja Microsoft 365:ssä. Jaettujen postilaatikoiden käsittelyyn tarvitaan ylläpitäjätason pääsy yhteyden valtuuttamiseen. Prosessi on sama kuin henkilökohtaisissa postilaatikoissa: analyysi, korjaus, varmennus.
Haluatko palauttaa oikeat päivämäärät? Käynnistä ilmainen analyysi ja selvitä kuinka monta sähköpostia on vaikuttunut kussakin postilaatikossa.