POP į IMAP: seni laiškai rodo šiandienos datą

Klasikinis pirmadienio ryto scenarijus

Ką tik perjungėte el. pašto paskyrą nuo POP3 prie IMAP. Konfigūracija buvo paprasta, prieglobos paslaugų teikėjas padėjo, viskas pavyko sklandžiai. Kol vėl neatidarysite gaunamųjų laiškų dėžutės. Jūsų 2019, 2021 metų el. laiškai, praėjusių metų archyvai... visi rodo tą pačią datą: šiandien. Kartais net tą pačią valandą, kelių sekundžių tikslumu.

Tai nėra el. pašto kliento klaida. Tai ne laiko juostos problema. Tai yra numatomas IMAP protokolo elgesys, kuris paliečia kiekvieną, kas per šį metodą kelia lokalioje mašinoje saugotus el. laiškus į serverį.

POP3 ir IMAP: esminis saugojimo skirtumas

Norint suprasti, kodėl problema kyla, reikia suprasti, kaip veikia POP3 ir kuo tai iš esmės skiriasi nuo IMAP.

Su POP3 serveris tarnauja tik kaip laikina pašto dėžutė. Jūsų klientas (Outlook, Thunderbird, Apple Mail) prisijungia, atsiunčia pranešimus, tada ištrina juos iš serverio (arba palieka, priklausomai nuo jūsų konfigūracijos). Laiškai toliau gyvena išskirtinai lokaliai: .pst faile Outlook atveju, Thunderbird lokaliame profilyje, duomenų bazėje jūsų kietajame diske.

Su IMAP viskas atvirkščiai: laiškai gyvena serveryje. Klientas tik rodo, kas saugoma nuotoliniu būdu. Iš čia kyla skaidrus sinchronizavimas tarp visų jūsų įrenginių.

Problema iškyla pereinant tarp dviejų protokolų. Kai keliami lokalūs POP laiškai į IMAP serverį.

IMAP APPEND: komanda, kuri viską keičia

Kai el. pašto klientas kelia lokalų pranešimą į IMAP serverį, jis naudoja komandą IMAP APPEND. Ši komanda serveriui sako: "išsaugok šį pranešimą tokiame ir tokiame aplanke".

Serveris gauna pranešimą, išsaugo jį ir priskiria laiko žymę. Ta laiko žymė yra INTERNALDATE. Tai yra centriniai IMAP metaduomenys: jie nurodo, kada pranešimas buvo įkeltas į serverį. Ir pagal nutylėjimą, jei klientas komandoje APPEND nenurodo datos, serveris naudoja... šio momento datą.

Kitaip tariant: nesvarbu, kad pranešimas antraštėse turi 2018 metų datą. Jei niekas serveriui nepasako "šis el. laiškas iš 2018 metų", serveris nusprendžia, kad jis buvo įkeltas dabar, ir priskiria jam šiandienos INTERNALDATE.

(Beje, jei kada nors žiūrėjote į neapdorotus el. laiško antraštes, matėte eilutę Date: tarp dešimties kitų Received: eilučių. Būtent šis laukas Date:, apibrėžtas RFC 2822, saugo tikrąją siuntimo datą. Tačiau IMAP INTERNALDATE yra atskiri metaduomenys, saugomi serverio pusėje, kurie neturi nieko bendra su paties pranešimo turiniu.)

Kodėl tai skiriasi nuo IMAP į IMAP migracijos

Klasikinės migracijos iš vieno IMAP serverio į kitą atveju (su BitTitan, CloudM, imapsync ir kt.) problema yra šiek tiek kitokia. Migracijos įrankis kopijuoja pranešimus iš vieno serverio į kitą, ir tokiu atveju jis gali (teoriškai) perduoti originalų INTERNALDATE į paskirties serverį per APPEND komandą. Ten problema yra ta, kad kai kurie įrankiai prideda Received: antraštę su migracijos data, o tai trikdo rodymą klientuose, kaip Outlook.

Jūsų atveju pradedate nuo grynai lokalių duomenų. Nėra jokio šaltinio INTERNALDATE, kurį būtų galima kopijuoti. .pst failas ar Thunderbird profilis saugo pranešimus savo nuosavuoju formatu su savo vidiniais metaduomenimis. Kai el. pašto klientas perskaito šiuos pranešimus, kad juos įkeltų į IMAP serverį, jis iš naujo sukonstruoja APPEND komandą iš pranešimo turinio. Ir dažniausiai jis neperduoda aiškios datos.

Rezultatas: IMAP serveris per kelias minutes gauna šimtus ar tūkstančius pranešimų ir visiems priskiria tą patį laiko intervalą: dabar.

Būtent todėl problema akimirksniu paplinta visuose jūsų įrenginiuose. Jūsų telefonas, planšetė, antras kompiuteris, visi jungiasi prie to paties IMAP serverio ir mato lygiai tą patį. Jokio taisymo galimybės kliento pusėje.

Kuris klientas rodo ką ir kodėl

Ne visi el. pašto klientai reaguoja vienodai. Tai yra dalykas, kurį daugelis IT administratorių atranda per vėlai.

Outlook (naujesnėse versijose, ypač po 2023-2024 metų atnaujinimų) naudoja serverio INTERNALDATE stulpelyje "Gauta". Todėl jis rodo įkėlimo datą, o ne originalią siuntimo datą. Daugiau apie šį specifinį Outlook elgesį rasite čia: Outlook: IMAP migracijos data vs siuntimo data.

Gmail / Google Workspace ir Thunderbird elgiasi kiek sudėtingiau. Gmail, pavyzdžiui, kartais gali naudoti pranešimo antraštės lauką Date: rodymui, kas sukuria įspūdį, kad viskas gerai... kol nebandysite rūšiuoti pagal datą ir nesuprasite, kad tvarka visiškai atsitiktinė.

Apple Mail paprastai rodo datą, ištrauktą iš antraštės Date:, tačiau rūšiavimas ir paieška fone vyksta per INTERNALDATE. Taigi jūsų laiškai gali vizualiai "atrodyti" tinkamai datuoti, bet rūšiavimo funkcija nebeveikia teisingai. Dėl Apple Mail elgesio detalių žr. Apple Mail: klaidinga data po migracijos.

Gera žinia: originali data nepaliesta

Kiekvieno el. laiško antraštė Date:, ta, kurioje yra tikroji siuntimo (ar gavimo) data, nebuvo paliesta. Ji vis dar yra, pranešimo viduje. Tai ji matoma, kai atidarote el. laišką ir žiūrite į detales.

IMAP serveris "sugadino" tik INTERNALDATE, tą išorinį pranešimo metaduomenį. Pats pranešimas yra nepažeistas.

Būtent tai ir daro taisymą įmanomu. Ir tai paaiškina, kodėl problema gali kurį laiką likti nepastebėta: laiškai atrodo teisingi, kai atidarote juos po vieną. Problema tampa matoma tik žiūrint į gaunamųjų sąrašą, surūšiuotą pagal datą. 2019 metų laiškai pasirodo viršuje, tarsi būtų ką tik atėję. Visi su ta pačia data.

Masto problema: 3000 laiškų skiriasi nuo 3

Galbūt galvojate: "Tiesiog ištrinsiu ir importuosiu iš naujo, šį kartą teisingai." Su 5 ar 10 bandomaisiais el. laiškais taip, tai veikia. Su 8000 pranešimų dėžute, turinčia įdėtus aplankus, didelius priedus, S/MIME pasirašytus laiškus ir diskusijų gijas nuo 2015 metų... tai jau visai kita istorija.

Namų gamybos skriptas, veikiantis su 50 bandomųjų el. laiškų partija, gali labai lengvai sukurti dublikatus, prarasti priedus ar sulaužyti pokalbių gijas gamybinėje dėžutėje. API kvotų valdymas, tinklo laiko limitai, netipiškos MIME struktūros pranešimai... kiek daug kraštutinių atvejų, kurių nespecializuotas įrankis nepalaiko.

O jei kažkas sugestų pusiaukelėje? Be atsarginės kopijos ir grąžinimo mechanizmo, prarandate duomenis be galimybės juos atgauti.

Ši problema gerai žinoma administratoriams, valdantiems dideles migracijas. Suprasti, kodėl datos sulaužytos, yra vienas dalykas. Tinkamai pataisyti 15000 el. laiškų, išsaugant kiekvieną pranešimo struktūrą, yra visai kas kita. Norėdami sužinoti daugiau šia tema, straipsnis Ar galima pataisyti el. laiškų datas po migracijos? išsamiai aprašo įvairius metodus ir jų ribas.

Kaip Redate.io tvarko šį konkretų atvejį

Redate.io buvo sukurtas būtent tokioms situacijoms. Jo analizės variklis identifikuoja el. laiškus, kurių INTERNALDATE neatitinka datos, esančios pranešimo antraštėse, nesvarbu, ar tai POP į IMAP migracija, migracija tarp IMAP serverių, ar rankinis lokalių archyvų įkėlimas.

Daugiapakopis analizės konvejeris tikrina kiekvieno pranešimo antraščių grandinę, patvirtina RFC atitikimą ir atstatyto datos metaduomenis, nepakeičiant pranešimo turinio: nei teksto, nei priedų, nei MIME struktūros, nei galimų skaitmeninių parašų. Kiekvienas pataisytas el. laiškas yra patikrinamas individualiai prieš patvirtinimą.

Originalai saugomi matomame atsarginės kopijos aplanke 30 dienų. Jei kažkas netinka, galite atkurti.

Pradinis nuskaitymas yra nemokamas: Redate analizuoja jūsų dėžutę, identifikuoja paveiktus el. laiškus ir nurodo tikslų skaičių prieš tai, kai nusprendžiate ką nors daryti. Jokių aklų įsipareigojimų.

Redate.io tiesiogiai prisijungia prie jūsų dėžučių per Google Workspace (domeno delegavimą), Microsoft 365 (Azure AD) arba tiesioginį IMAP. Jokios lokalios instaliacijos. Jokio rankinio .pst failų eksporto.

Administratoriams, valdantiems kelias dėžutes ir norintiems pasidalinti patirtimi apie tokius atvejus, straipsnis MSP: kaip pataisyti klientų el. pašto datas yra geras papildomas skaitinys. O dėl Thunderbird specifikos per POP/IMAP perėjimą, žr. Thunderbird: klaidinga data po migracijos.

Jei dar tik planuojate: kaip išvengti problemos

Jei dar neįkėlėte lokalių archyvų į IMAP serverį, arba planuojate migruoti daugiau POP paskyrų savo organizacijoje, štai ką verta turėti omenyje.

• Patikrinkite, ar jūsų el. pašto klientas palaiko aiškų datos perdavimą APPEND komandoje. Thunderbird, pavyzdžiui, turėjo skirtingą elgesį skirtingose versijose šiuo klausimu.
• Pirmiausia atlikite testą su tikrinimo paskyra, naudojant 50-100 reprezentatyvių pranešimų: seni laiškai, su priedais, pasirašyti laiškai. Patikrinkite rodomas datas skirtinguose klientuose.
• Planuokite taisymą prieš tai, kai galutiniai vartotojai pradeda dirbti su migravusiąja dėžute. Datų taisymas aktyvioje dėžutėje yra sudėtingesnis nei tuščioje po migracijos.
• Dokumentuokite el. laiškų skaičių prieš ir po migracijos. Tai vienintelis būdas aptikti tylias netektis.

Išsamų kontrolinį sąrašą su visais tikrinimo punktais rasite čia: El. pašto migracijos kontrolinis sąrašas: kaip išvengti datų problemų.

Jūsų seni laiškai rodo šiandienos datą po perėjimo nuo POP prie IMAP? Paleiskite nemokamą nuskaitymą Redate.io, kad išmatuotumėte problemos mastą ir ištaisytumėte datos metaduomenis nepaliesdami laiškų turinio.