POP IMAP-ile: vanad meilid näitavad tänast kuupäeva

Esmaspäeva hommiku klassikaline olukord

Olete just lülitanud oma e-posti konto POP3-lt IMAP-ile. Seadistamine oli lihtne, majutusteenuse pakkuja juhendas teid, kõik läks sujuvalt. Kuni te postkasti uuesti avasite. Teie 2019. ja 2021. aasta meilid, eelmise aasta arhiivid... kõik näitavad sama kuupäeva: täna. Mõnikord isegi sama kellaaega, sekundite täpsusega.

See ei ole teie meilirakenduse viga. See ei ole ajavööndiprobleem. See on IMAP-protokolli oodatav käitumine ja see mõjutab kõiki, kes tõstavad kohalikult salvestatud e-kirju serverisse selle meetodi abil.

POP3 vs IMAP: põhimõtteline erinevus salvestamises

Et mõista, miks probleem tekib, tuleb esmalt aru saada, kuidas POP3 töötab ja mille poolest see IMAP-ist radikaalselt erineb.

POP3 puhul on server vaid ajutine postkast. Teie rakendus (Outlook, Thunderbird, Apple Mail) ühendub, laadib sõnumid alla, seejärel kustutab need serverist (või jätab sõltuvalt teie seadistusest). Meilid elavad edaspidi ainult kohalikult: Outlooki puhul .pst-failis, Thunderbirdi kohalikus profiilis, kõvaketta andmebaasis.

IMAP-iga on vastupidi: meilid elavad serveris. Teie rakendus kuvab vaid seda, mis on kaugserveris salvestatud. Siit tuleb ka sujuv sünkroonimine kõigi seadmete vahel.

Probleem tekib kahe süsteemi vahel üleminekul, nimelt siis, kui tõstate vanad POP-i kohalikud meilid IMAP-serverisse.

IMAP APPEND: käsk, mis kõik muudab

Kui teie meilirakendus tõstab kohaliku sõnumi IMAP-serverisse, kasutab ta käsku IMAP APPEND. See käsk ütleb serverile: "salvesta see sõnum sellesse kausta".

Server võtab sõnumi vastu, salvestab selle ja omistab talle ajatempli. See ajatempel on INTERNALDATE. See on IMAP-i keskne metaandmete väli: see näitab, millal sõnum serverisse jõudis. Ja vaikimisi, kui rakendus ei täpsusta APPEND-käsus kuupäeva, kasutab server... praegust hetke.

Teisisõnu: ükskõik, kas sõnumi päistes on 2018. aasta kuupäev, kui keegi ei ütle serverile "see meil on 2018. aastast", järeldab server, et see deposeeriti just nüüd, ja omistab talle tänase INTERNALDATE.

(Muide, kui olete kunagi e-kirja toorseid päiseid vaadanud, olete näinud rida Date: kümnete teiste Received:-ridade keskel. See RFC 2822 poolt määratletud väli Date: sisaldab tegelikku saatmiskuupäeva. Kuid IMAP INTERNALDATE on eraldi metaandmete väli, mis on serveris salvestatud ja millel pole midagi pistmist sõnumi sisuga.)

Miks see erineb IMAP-ilt IMAP-ile migreerimisest

Klassikalise IMAP-serverilt teisele migreerimise puhul (BitTitani, CloudM-i, imapsync-i jms abil) on probleem veidi erinev. Migratsioonitööriist kopeerib sõnumid ühelt serverilt teisele ja sel juhul saab see (teoreetiliselt) edastada algse INTERNALDATE sihtserverile APPEND-käsu kaudu. Seal on probleem see, et mõned tööriistad lisavad migratsioonikuupäevaga Received:-päise, mis segab kuvamist klientides nagu Outlook.

Teie juhul lähtute puhtalt kohalikest andmetest. Kopeeritavat algset INTERNALDATE ei ole. .pst-fail või Thunderbirdi profiil salvestab sõnumeid oma omanduslikus vormingus, oma sisemiste metaandmetega. Kui meilirakendus loeb need sõnumid IMAP-serverisse tõstmiseks uuesti läbi, koostab ta APPEND-käsu sõnumi sisu põhjal. Enamasti ei edasta see selget kuupäeva.

Tulemus: IMAP-server saab mõne minutiga sadu või tuhandeid sõnumeid ja omistab kõigile sama ajavahemiku: praegu.

Just seetõttu levib probleem kohe kõigisse seadmetesse. Teie telefon, tahvelarvuti, teine arvuti: kõik ühenduvad sama IMAP-serveriga ja näevad täpselt sama asja. Kliendipoolne parandamine on võimatu.

Milline rakendus mida kuvab ja miks

Kõik meilirakendused ei käitu ühtmoodi. See on midagi, mida paljud IT-administraatorid avastavad alles hiljem.

Outlook (uuemates versioonides, eriti pärast 2023-2024 uuendusi) kasutab veeru "Saadud" jaoks serveri INTERNALDATE-i. Seega kuvab see üleslaadimise kuupäeva, mitte algset saatmiskuupäeva. Selle Outlooki-spetsiifilise käitumise kohta on kasulik lugeda: Outlook: IMAP-migratsioonil vastuvõetud kuupäev vs saadetud kuupäev.

Gmail/Google Workspace ja Thunderbird käituvad veidi nüanseeritumalt. Gmail võib mõnikord kasutada kuvamiseks sõnumi päise välja Date:, mis annab mulje, et kõik on korras... kuni proovite kuupäeva järgi sortida ja avastate, et järjekord on täiesti juhuslik.

Apple Mail kuvab üldjuhul päisest Date: eraldatud kuupäeva, kuid sortimine ja otsing kasutavad taustal INTERNALDATE-i. Seega võivad teie meilid visuaalselt "näida" õigesti dateerituna, kuid sortimine ei tööta enam korralikult. Apple Maili käitumise kohta vt Apple Mail: vale kuupäev pärast migratsiooni.

Hea uudis: algne kuupäev on puutumata

Iga meili päise väli Date:, mis sisaldab tegelikku saatmis- (või kättesaamis-) kuupäeva, pole muutunud. See on endiselt seal, sõnumi sees. See on see, mida näete, kui avate meili ja vaatate üksikasju.

See, mida IMAP-server "katkestas", on ainult INTERNALDATE, see sõnumivälise metaandmete väli. Sõnum ise on terve.

Just see teeb parandamise võimalikuks. Ja see seletab ka, miks probleem võib mõnda aega märkamatuks jääda: meilid näivad õiged, kui avate neid ükshaaval. Alles postkasti nimekirja kuupäeva järgi sortides muutub probleem nähtavaks. 2019. aasta meilid ilmuvad üles justkui äsja saabunud. Kõik sama kuupäevaga.

Mastaabi probleem: 3000 meili on 3-st erinev

Võib-olla mõtlete: "Kustutan lihtsalt kõik ja impordin uuesti, seekord õigesti." Viie või kümne testsõnumiga töötab see jah. 8000 sõnumiga postkastiga, millel on pesastatud kaustad, mahukad manused, S/MIME-allkirjastatud meilid ja 2015. aastast pärit arutelulõimed... see on hoopis teine lugu.

Omatehtud skript, mis töötab 50-sõnumilise testipartii peal, võib tootmispostkastis täiesti hästi produtseerida duplikaate, kaotada manuseid või katkestada vestluslõimed. API-kvootide haldamine, võrgu-timeoutid, ebatüüpiliste MIME-struktuuridega sõnumid... need on piirjuhtumid, mida mittespetsialiseeritud tööriist ei käsitle.

Ja kui midagi poolel teel valesti läheb? Ilma varundusmehhanismita ja tagasipööramisvõimaluseta kaotate andmeid, ilma et saaksite neid taastada.

See probleem on hästi tuntud suuri migratsioone haldavatele administraatoritele. Mõista, miks kuupäevad on katkised, on üks asi. 15 000 meili korralikult parandada, säilitades iga sõnumi struktuuri, on hoopis teine. Lähemalt käsitleb seda teemat artikkel Kas e-kirjade kuupäevi saab pärast migratsiooni parandada?, mis kirjeldab erinevaid lähenemisi ja nende piiranguid.

Kuidas Redate.io selle konkreetse olukorraga toime tuleb

Redate.io on loodud täpselt seda tüüpi olukordade jaoks. Selle analüüsimootor tuvastab meilid, mille INTERNALDATE ei vasta sõnumi päistes sisalduvale kuupäevale, olgu tegemist POP-ilt IMAP-ile ülemineku, IMAP-serverite vahelise migratsiooni või kohalike arhiivide käsitsi üleslaadimisega.

Mitmeetapiline analüüsikonveier uurib iga sõnumi päiseahelat, valideerib RFC-vastavuse ja rekonstrueerib kuupäeva metaandmed, muutmata sõnumi sisu: ei teksti, ei manuseid, ei MIME-struktuuri ega digitaalallkirju. Iga parandatud meil kontrollitakse individuaalselt enne kinnitamist.

Originaalid säilitatakse nähtavas varunduskaustas 30 päeva. Kui midagi ei sobi, saate taastada.

Esmane skannimine on tasuta: Redate analüüsib teie postkasti, tuvastab mõjutatud meilid ja teatab täpse arvu enne, kui teete ühtegi otsust. Pimesi kohustust ei võeta.

Redate.io ühendub otse teie postkastidega Google Workspace'i (domeenidelegatsioon), Microsoft 365 (Azure AD) või IMAP-ühenduse kaudu. Kohalikku installatsiooni ei ole vaja. .pst-faile ei pea käsitsi eksportima ega importima.

Administraatoritele, kes haldavad mitut postkasti ja soovivad selliste juhtumite kohta rohkem teada, on MSP: e-kirjade kuupäevade parandamine kasulik täiendav lugemine. Thunderbirdi-spetsiifiliste korrektsioonide kohta, millel on POP/IMAP-üleminekul oma käitumine, vt Thunderbird: vale kuupäev pärast migratsiooni.

Kui see on veel ees: probleemi ennetamine

Kui te pole veel kohalikke arhiive IMAP-serverisse üles tõstnud või planeerite organisatsioonis täiendavaid POP-kontode migratsioone, pidage silmas järgmist.

• Kontrollige, kas teie meilirakendus toetab kuupäeva eksplitsiitset edastamist APPEND-käsus. Thunderbird on näiteks erinevate versioonide lõikes selles osas käitunud erinevalt.
• Tehke esmalt test valideerimiskontol 50-100 esindavat sõnumit kasutades: vanad meilid, manustega meilid, allkirjastatud meilid. Kontrollige erinevates rakendustes kuvatavaid kuupäevi.
• Planeerige parandus enne, kui lõppkasutajad hakkavad migreeritud postkastis tööd tegema. Kuupäevade parandamine aktiivsel postkastil on keerulisem kui migratsiooni järgsel tühjal postkastil.
• Dokumenteerige meilide arv enne ja pärast migratsiooni. See on ainus viis vaiksete kaotuste tuvastamiseks.

Täieliku kontrollnimekirja saamiseks kõige kohta, mida enne ja pärast migratsiooni kontrollida, vt artiklit E-posti migratsioon: kuupäevaprobleemide ennetamise kontrollnimekiri.

Teie vanad meilid näitavad pärast POP-ilt IMAP-ile üleminekut tänast kuupäeva? Käivitage Redate.io tasuta skannimine, et mõõta probleemi ulatust ja parandada kuupäeva metaandmeid, muutmata meili sisu.