POP uz IMAP: vecie e-pasti rāda šodienas datumu

Klasisks pirmdienas rīta scenārijs

Jūs tikko pārslēdzāt savu e-pasta kontu no POP3 uz IMAP. Konfigurācija bija vienkārša, pakalpojumu sniedzējs jūs vadīja, viss noritēja gludi. Līdz brīdim, kad atvērāt iesūtni. Jūsu e-pasti no 2019., 2021. gada, pagājušā gada arhīvi... visi rāda to pašu datumu: šodien. Dažkārt pat to pašu laiku, ar dažu sekunžu nobīdi.

Tā nav jūsu e-pasta klienta kļūda. Tā nav laika joslas problēma. Tā ir sagaidāma IMAP protokola uzvedība, un tā skar ikvienu, kas uz servera augšupielādē lokāli glabātus e-pastus, izmantojot šo metodi.

POP3 pret IMAP: fundamentāla glabāšanas atšķirība

Lai saprastu, kāpēc problēma rodas, vispirms jāsaprot, kā darbojas POP3, un kāpēc tas ir principiāli atšķirīgs no IMAP.

Ar POP3 serveris ir tikai pagaidu pastkastes analogs. Jūsu klients (Outlook, Thunderbird, Apple Mail) pieslēdzas, lejupielādē ziņojumus, pēc tam tos no servera dzēš (vai atstāj, atkarībā no iestatījumiem). E-pasti pēc tam dzīvo tikai lokāli: Outlook gadījumā .pst failā, Thunderbird lokālajā profilā, datu bāzē jūsu cietajā diskā.

Ar IMAP ir pretēji: e-pasti glabājas serverī. Klients tikai attēlo attālināti glabāto saturu. No tā izriet caurspīdīga sinhronizācija starp visām ierīcēm.

Problēma rodas pārejas brīdī starp abiem. Kad augšupielādējat lokālos POP e-pastus uz IMAP serveri.

IMAP APPEND: komanda, kas maina visu

Kad jūsu e-pasta klients augšupielādē lokālu ziņojumu uz IMAP serveri, tas izmanto komandu IMAP APPEND. Šī komanda serverim saka: "saglabā šo ziņojumu šajā mapē".

Serveris saņem ziņojumu, to ieraksta un piešķir laika zīmogu. Šis laika zīmogs ir INTERNALDATE. Tā ir centrālā IMAP metadatu vienība: tā norāda, kad ziņojums tika nogādāts serverī. Pēc noklusējuma, ja klients komandā APPEND nenorāda datumu, serveris izmanto... pašreizējo brīdi.

Citiem vārdiem: nav svarīgi, ka ziņojuma galvenēs ir 2018. gada datums. Ja neviens nepaziņo serverim "šis e-pasts ir no 2018. gada", serveris secina, ka tas tikko nogādāts, un piešķir šodienas INTERNALDATE.

(Starp citu, ja kādreiz esat skatījuši e-pasta neapstrādātās galvenes, redzējāt rindiņu Date: starp desmitiem citu Received: rindiņu. Šis Date: lauks, ko nosaka RFC 2822, satur patieso nosūtīšanas datumu. Taču IMAP INTERNALDATE ir atsevišķa metadatu vienība, glabāta servera pusē, kas nekādi nav saistīta ar paša ziņojuma saturu.)

Kāpēc tas atšķiras no IMAP-uz-IMAP migrācijas

Klasiskā migrācijā no viena IMAP servera uz otru (izmantojot BitTitan, CloudM, imapsync u.c.) problēma ir nedaudz atšķirīga. Migrācijas rīks kopē ziņojumus starp serveriem, un šajā gadījumā tas teorētiski var nodot sākotnējo INTERNALDATE mērķa serverim caur APPEND komandu. Tur problēma ir tā, ka daži rīki pievieno Received: galveni ar migrācijas datumu, kas izjauc attēlojumu klientos kā Outlook.

Jūsu gadījumā jūs sākat no pilnībā lokāliem datiem. Nav avota INTERNALDATE, ko kopēt. .pst fails vai Thunderbird profils glabā ziņojumus savā patentētajā formātā ar savām iekšējām metadatām. Kad e-pasta klients nolasa šos ziņojumus, lai tos augšupielādētu uz IMAP serveri, tas no jauna veido APPEND komandu, balstoties uz ziņojuma saturu. Un vairumā gadījumu tas nenorāda datumu.

Rezultāts: IMAP serveris dažu minūšu laikā saņem simtiem vai tūkstošiem ziņojumu un visiem piešķir to pašu laika joslu: tagad.

Tieši tāpēc problēma momentāni izplatās uz visām jūsu ierīcēm. Tālrunis, planšetdators, otrais dators: visi pieslēdzas tam pašam IMAP serverim un redz tieši to pašu. Klienta pusē labojums nav iespējams.

Kurš klients rāda ko, un kāpēc

Ne visi e-pasta klienti uzvedas vienādi. Daudzi IT administratori to atklāj tikai pēc fakta.

Outlook (jaunākajās versijās, īpaši kopš 2023.-2024. gada atjauninājumiem) izmanto servera INTERNALDATE slejā "Saņemts". Tas rāda augšupielādes datumu, nevis sākotnējo nosūtīšanas datumu. Vairāk par šo Outlook specifisko uzvedību lasiet šeit: Outlook: IMAP saņemšanas datums vs nosūtīšanas datums.

Gmail / Google Workspace un Thunderbird ir nedaudz nianšētāki. Gmail, piemēram, dažkārt var izmantot ziņojuma galvenes Date: lauku attēlojumam, radot iespaidu, ka viss ir kārtībā... līdz brīdim, kad mēģināt kārtot pēc datuma un saprotat, ka secība ir pilnīgi nejauša.

Apple Mail parasti rāda datumu no Date: galvenes, taču kārtošana un meklēšana fonā izmanto INTERNALDATE. Līdz ar to e-pasti vizuāli var "izskatīties" pareizi datēti, bet kārtošanas funkcija vairs nedarbojas pareizi. Sīkāk par Apple Mail uzvedību: Apple Mail: nepareizs datums pēc migrācijas.

Labā ziņa: sākotnējais datums ir neskarts

Katra e-pasta Date: galvene, kas satur patieso nosūtīšanas (vai saņemšanas) datumu, nav aiztikta. Tā joprojām atrodas ziņojuma saturā. To jūs redzat, atverot e-pastu un skatot detaļas.

Ko IMAP serveris "salauza", ir tikai INTERNALDATE, šī ziņojumam ārējā metadatu vienība. Pats ziņojums ir neskarts.

Tieši tāpēc labojums ir iespējams. Un tāpēc arī problēma var palikt nepamanīta kādu laiku: e-pasti izskatās pareizi, atverot tos vienu pēc otra. Problēma kļūst redzama tikai skatot iesūtnes sarakstu, sakārtotu pēc datuma. 2019. gada e-pasti parādās augšā it kā tikko saņemti. Visi ar to pašu datumu.

Mēroga problēma: 3000 e-pasti nav tas pats, kas 3

Varbūt domājat: "Dzēsīšu un reimportēšu, šoreiz pareizi." Uz 5 vai 10 testa e-pastiem, jā, tas strādā. Uz pastkasti ar 8000 ziņojumiem, ligzdotām mapēm, apjomīgiem pielikumiem, S/MIME parakstītiem e-pastiem un diskusiju pavedieniem, kas aizsniedzas līdz 2015. gadam... tā ir pavisam cita lieta.

Mājas darba skripts, kas darbojas uz 50 testa e-pastu partiju, ražošanas pastkastē var radīt dublikātus, pazaudēt pielikumus vai salauzt sarunas pavedienus. API kvotu pārvaldība, tīkla noildzes, netipiskām MIME struktūrām ar ziņojumi... tie visi ir robežgadījumi, ar kuriem nespecializēts rīks netiek galā.

Un ja kaut kas noiet greizi pa vidu? Bez dublēšanas un atjaunošanas mehānisma dati tiek zaudēti bez iespējas tos atgūt.

Šī problēma labi pazīstama administratoriem, kas pārvalda apjomīgas migrācijas. Saprast, kāpēc datumi ir bojāti, ir viena lieta. Pareizi labot 15 000 e-pastus, saglabājot katru ziņojuma struktūru, ir pavisam cita. Lai uzzinātu vairāk par šo tēmu, raksts Vai e-pastu datumus var labot pēc migrācijas? detalizēti aplūko dažādas pieejas un to ierobežojumus.

Kā Redate.io tiek galā ar šo konkrēto gadījumu

Redate.io ir izstrādāts tieši šāda veida situācijām. Tā analīzes dzinējs identificē e-pastus, kuriem INTERNALDATE nesakrīt ar datumu ziņojuma galvenēs, neatkarīgi no tā, vai runa ir par POP uz IMAP migrāciju, migrāciju starp IMAP serveriem vai manuālu lokālo arhīvu augšupielādi.

Daudzpakāpju analīzes cauruļvads pārbauda katru ziņojumu galveņu ķēdi, validē RFC atbilstību un rekonstruē datuma metadatus, nemainot ziņojuma saturu: ne tekstu, ne pielikumus, ne MIME struktūru, ne digitālus parakstus. Katrs labotais e-pasts tiek individuāli pārbaudīts pirms apstiprināšanas.

Oriģināli tiek glabāti redzamā dublēšanas mapē 30 dienas. Ja kaut kas neder, var atjaunot.

Sākotnējā skenēšana ir bezmaksas: Redate analizē jūsu pastkasti, identificē skartus e-pastus un norāda precīzu skaitu pirms jūs kaut ko izlemjat. Nekādu aklu saistību.

Redate.io pieslēdzas jūsu pastkastēm tieši caur Google Workspace (domēna deleģēšanu), Microsoft 365 (Azure AD) vai IMAP tieši. Nav lokālas instalācijas. Nav .pst failu, kas jāapstrādā manuāli.

Administratoriem, kas pārvalda vairākas pastkastes un vēlas uzzināt vairāk par šāda veida gadījumiem, raksts MSP: klientu e-pastu datumu labošana ir noderīgs papildinājums. Par Thunderbird korekcijas specifikām, kas POP/IMAP pārejas laikā uzvedas savdabīgi, skatiet Thunderbird: nepareizs datums pēc migrācijas.

Ja vēl priekšā: kā sagatavoties iepriekš

Ja vēl neesat augšupielādējuši lokālos arhīvus uz IMAP serveri vai plānojat turpmākas POP kontu migrācijas savā organizācijā, lūk, kas jāpatur prātā.

• Pārbaudiet, vai jūsu e-pasta klients atbalsta datuma nodošanu APPEND komandā. Thunderbird, piemēram, šajā jautājumā dažādās versijās ir uzvedies atšķirīgi.
• Vispirms veiciet testu ar validācijas kontu, izmantojot 50-100 reprezentatīvus ziņojumus: vecus e-pastus, ar pielikumiem, parakstītus e-pastus. Pārbaudiet attēlotos datumus dažādos klientos.
• Plānojiet labojumu pirms gala lietotāji sāk strādāt ar migrēto pastkasti. Datumu labošana aktīvā pastkastē ir sarežģītāka nekā tukšā pēc migrācijas.
• Dokumentējiet e-pastu skaitu pirms un pēc migrācijas. Tas ir vienīgais veids, kā atklāt kluso datu zudumu.

Pilnīgu kontrolsarakstu ar pārbaudāmiem punktiem pirms un pēc migrācijas skatiet šeit: E-pasta migrācijas kontrolsaraksts: datumu problēmu novēršana.

Jūsu vecie e-pasti rāda šodienas datumu pēc pārejas no POP uz IMAP? Palaidiet bezmaksas skenēšanu Redate.io, lai novērtētu problēmas apmēru un labotu datuma metadatus, nemainot ziņojumu saturu.