Prehod s POP na IMAP: stari e-maili prikazujejo današnji datum

Klasičen ponedeljkov zjutraj

Ravnokar ste preklopili e-poštni račun s POP3 na IMAP. Nastavitev je bila preprosta, ponudnik vas je vodil korak za korakom, vse je steklo gladko. Dokler niste znova odprli nabiralnika. E-maili iz leta 2019, 2021, arhivi preteklega leta... vsi prikazujejo isti datum: danes. Včasih celo isto uro, z razliko le nekaj sekund.

To ni napaka v vašem e-poštnem odjemalcu. To ni težava s časovnim pasom. To je pričakovano vedenje protokola IMAP, ki prizadene vsakogar, ki lokalno shranjene e-maile prenaša na strežnik s to metodo.

POP3 in IMAP: temeljna razlika v shranjevanju

Da bi razumeli, zakaj do težave pride, je treba najprej razumeti, kako deluje POP3 in v čem se bistveno razlikuje od IMAP.

Pri POP3 strežnik služi zgolj kot začasno poštno nabiralnik. Vaš odjemalec (Outlook, Thunderbird, Apple Mail) se poveže, prenese sporočila in jih s strežnika izbriše (ali pusti, odvisno od nastavitev). E-maili nato živijo izključno lokalno: v datoteki .pst za Outlook, v lokalnem profilu Thunderbirda ali v podatkovni bazi na vašem disku.

Pri IMAP je ravno obratno: e-maili živijo na strežniku. Odjemalec le prikazuje, kar je shranjeno na oddaljenem mestu. Odtod izhaja brezhibna sinhronizacija med vsemi napravami.

Težava nastopi pri prehodu med obema. Ko lokalne POP e-maile naložite na strežnik IMAP.

IMAP APPEND: ukaz, ki vse spremeni

Ko e-poštni odjemalec nalaga lokalno sporočilo na strežnik IMAP, uporabi ukaz IMAP APPEND. Ta ukaz strežniku pove: "shrani to sporočilo v ta map".

Strežnik sporočilo prejme, ga zabeleži in mu dodeli časovni žig. Ta časovni žig je INTERNALDATE. To je osrednji metapodatek IMAP: označuje, kdaj je bilo sporočilo položeno na strežnik. In privzeto, če odjemalec v ukazu APPEND ne navede izrecnega datuma, strežnik uporabi... trenutni čas.

Z drugimi besedami: ne glede na to, da sporočilo v svojih glav vsebuje datum iz leta 2018, če nihče strežniku ne pove "ta e-mail je iz leta 2018", strežnik sklepa, da je bilo pravkar dostavljeno, in mu dodeli INTERNALDATE z današnjim dnem.

(Mimogrede, če ste kdaj pogledali surove glave e-maila, ste videli vrstico Date: sredi ducata vrstic Received:. To polje Date:, definirano z RFC 2822, vsebuje pravi datum pošiljanja. Toda IMAP INTERNALDATE je ločen metapodatek, shranjen na strani strežnika, ki nima nikakršne zveze z vsebino samega sporočila.)

Zakaj se to razlikuje od migracije IMAP v IMAP

Pri klasični migraciji z enega strežnika IMAP na drugega (z orodji BitTitan, CloudM, imapsync itd.) je težava nekoliko drugačna. Orodje za migracijo kopira sporočila z enega strežnika na drugega in pri tem lahko (v teoriji) prenese izvirni INTERNALDATE na ciljni strežnik prek ukaza APPEND. Tam je težava ta, da nekatera orodja dodajo glavo Received: z datumom migracije, kar zmede prikaz v odjemalcih, kot je Outlook.

V vašem primeru pa izhajate iz čisto lokalnih podatkov. Ni izvornega INTERNALDATE, ki bi ga prenesli. Datoteka .pst ali profil Thunderbirda shranjuje sporočila v lastnem lastniškem formatu s svojimi notranjimi metapodatki. Ko e-poštni odjemalec ta sporočila prebere in jih nalaga na strežnik IMAP, rekonstruira ukaz APPEND iz vsebine sporočila. V večini primerov izrecnega datuma ne posreduje.

Rezultat: strežnik IMAP v nekaj minutah prejme stotine ali tisoče sporočil in vsem dodeli isto časovno obdobje: zdaj.

Natanko zato se težava takoj razširi na vse vaše naprave. Vaš telefon, tablica, drugi računalnik: vsi se povezujejo na isti strežnik IMAP in vidijo natanko isto. Na strani odjemalca ni mogoče nič popraviti.

Kateri odjemalec prikazuje kaj in zakaj

Vsi e-poštni odjemalci se ne odzivajo enako. To je točka, ki jo marsikakšen IT admin odkri prepozno.

Outlook (v novejših različicah, zlasti po posodobitvah 2023-2024) za stolpec "Prejeto" uporablja INTERNALDATE strežnika. Prikazuje torej datum nalaganja, ne izvirnega datuma pošiljanja. Več o tem specifičnem vedenju Outlooka najdete v članku Outlook: datum prejema IMAP vs datum pošiljanja.

Gmail / Google Workspace in Thunderbird se obnašata nekoliko bolj niansiran. Gmail na primer včasih za prikaz uporabi polje Date: iz glave sporočila, kar ustvarja vtis, da je vse v redu... dokler ne poskusite razvrstiti po datumu in ugotovite, da je vrstni red povsem naključen.

Apple Mail navadno prikazuje datum, izluščen iz glave Date:, toda razvrščanje in iskanje v ozadju temeljita na INTERNALDATE. Vaši e-maili so torej vizualno videti pravilno datirani, a funkcija razvrščanja ne deluje več pravilno. Podrobnosti o vedenju Apple Maila si oglejte v članku Apple Mail: napačen datum po selitvi.

Dobra novica: izvirni datum je nedotaknjen

Glava Date: vsakega e-maila, tista, ki vsebuje pravi datum pošiljanja (ali prejema), ni bila spremenjena. Še vedno je tam, v telesu sporočila. To je tisto, kar vidite, ko odprete e-mail in pogledate podrobnosti.

Strežnik IMAP je "pokvaril" le INTERNALDATE, ta zunanji metapodatek sporočila. Sporočilo samo je nedotaknjeno.

Prav to omogoča popravek. In prav to pojasnjuje, zakaj težava lahko ostane neopažena za nekaj časa: e-maili se zdijo pravilni, ko jih odprete enega za drugim. Šele ko pogledate seznam nabiralnika, razvrščen po datumu, težava postane očitna. E-maili iz leta 2019 se pojavljajo na vrhu, kot da so ravnokar prispeli. Vsi z istim datumom.

Težava obsega: 3000 e-mailov je drugače kot 3

Morda si mislite: "Samo izbrišem in znova uvozim, tokrat pravilno." Na 5 ali 10 testnih e-mailih - ja, deluje. Na nabiralniku z 8000 sporočili, ugnezdenimi mapami, obsežnimi prilogami, S/MIME podpisanimi e-maili in pogovornimi niti, ki segajo v leto 2015... pa je to povsem druga zgodba.

Domač skript, ki deluje na testnem paketu 50 e-mailov, lahko na produkcijskem nabiralniku brez težav povzroči podvajanje, izgubo prilog ali zlomljene pogovorne niti. Upravljanje kvoт API-ja, omrežnih prekoračitev časa, sporočil z atipičnimi strukturami MIME... vse to so robni primeri, ki jih nespecializirano orodje ne obvlada.

In če gre kaj narobe na pol poti? Brez mehanizma varnostne kopije in povrnitve izgubite podatke brez možnosti obnovitve.

Težava je dobro znana administratorjem, ki upravljajo obsežne migracije. Razumeti, zakaj so datumi pokvarjeni, je eno. Pravilno popraviti 15.000 e-mailov ob ohranitvi vsake strukture sporočila je povsem drugo. Podrobneje o tem govori članek Ali se datumi e-pošte lahko popravijo po selitvi?, ki opisuje različne pristope in njihove omejitve.

Kako Redate.io obravnava ta specifičen primer

Redate.io je bil zasnovan natanko za takšne situacije. Njegov analitični mehanizem prepozna e-maile, katerih INTERNALDATE se ne ujema z datumom, vsebovanim v glavi sporočila, ne glede na to, ali gre za migracijo POP v IMAP, migracijo med strežniki IMAP ali ročno nalaganje lokalnih arhivov.

Večstopenjski analitični cevovod pregleda verigo glav vsakega sporočila, preveri skladnost z RFC in rekonstruira metapodatke datuma, ne da bi spremenil vsebino sporočila: niti besedila, niti prilog, niti strukture MIME, niti morebitnih digitalnih podpisov. Vsak popravljeni e-mail je pred potrditvijo preverjen posamično.

Izvirniki so 30 dni shranjeni v vidni varnostni kopiji. Če karkoli ne ustreza pričakovanjem, je mogoče obnoviti.

Začetni pregled je brezplačen: Redate.io analizira vaš nabiralnik, prepozna prizadete e-maile in vam pred kakršno koli odločitvijo sporoči točno število. Brez zaveze na slepo.

Redate.io se neposredno poveže z vašimi nabiralniki prek Google Workspace (domensko pooblastilo), Microsoft 365 (Azure AD) ali neposredno prek IMAP. Nobene lokalne namestitve. Nobenega ročnega upravljanja z datotekami .pst.

Za administratorje, ki upravljajo več nabiralnikov in iščejo izkušnje iz prakse za tovrstne primere, je dober dopolnilni vir članek MSP: popravek datumov e-pošte pri strankah. Za posebnosti popravka v Thunderbirdu, ki ima pri prehodu POP/IMAP svoje specifično vedenje, pa si oglejte Thunderbird: napačen datum po selitvi.

Če je vse to šele pred vami: kako se izogniti težavi

Če lokalnih arhivov še niste naložili na strežnik IMAP, ali če v svoji organizaciji načrtujete dodatne migracije POP računov, je vredno upoštevati naslednje.

• Preverite, ali vaš e-poštni odjemalec podpira izrecno posredovanje datuma v ukazu APPEND. Thunderbird je imel pri tem glede na različice različna vedenja.
• Najprej izvedite test na preverjalnem računu s 50-100 reprezentativnimi sporočili: starejši e-maili, s prilogami, podpisana sporočila. Preverite prikazane datume v različnih odjemalcih.
• Popravek načrtujte, preden končni uporabniki začnejo delati z migriranim nabiralnikom. Popraviti datume na aktivnem nabiralniku je bolj zapleteno kot na svežem nabiralniku neposredno po migraciji.
• Dokumentirajte število e-mailov pred migracijo in po njej. To je edini način za odkrivanje tihih izgub.

Za popoln kontrolni seznam točk, ki jih je treba preveriti pred migracijo in po njej, si oglejte članek Kontrolni seznam selitve e-pošte: preprečite težave z datumi, ki pokriva vse primere.

Vaši stari e-maili prikazujejo današnji datum po prehodu s POP na IMAP? Zaženite brezplačen pregled na Redate.io in ugotovite obseg težave ter popravite metapodatke datumov, ne da bi se dotaknili vsebine vaših sporočil.