POP-ról IMAP-ra: a régi emailek mai dátumot mutatnak

A hétfő reggeli klasszikus jelenet

Átállította az email-fiókját POP3-ról IMAP-ra. A konfiguráció egyszerű volt, a tárhelyszolgáltató végigvezette a folyamaton, minden simán ment. Aztán újra megnyitotta a beérkező leveleket. A 2019-es, 2021-es emailek, a tavalyi archívum... mind ugyanazt a dátumot mutatja: a mai napot. Néha még ugyanazt az időpontot is, néhány másodpercnyi eltéréssel.

Ez nem a levelezőkliens hibája. Nem időzóna-probléma. Ez az IMAP protokoll várt viselkedése, és mindenkit érint, aki helyi tárolásból tölt fel emaileket egy szerverre ezen a módszeren keresztül.

POP3 vs. IMAP: alapvetően különböző tárolási logika

A probléma megértéséhez először azt kell tisztázni, hogyan működik a POP3, és miért tér el gyökeresen az IMAP-tól.

POP3-mal a szerver csupán ideiglenes postaládaként működik. A kliens (Outlook, Thunderbird, Apple Mail) csatlakozik, letölti az üzeneteket, majd törli őket a szerverről (vagy megtartja, a beállítástól függően). Az emailek ezután kizárólag helyi szinten léteznek: Outlooknál egy .pst fájlban, Thunderbirdnél a helyi profilban, valahol a merevlemezen.

IMAP-nál fordított a helyzet: az emailek a szerveren élnek. A kliens csupán megjeleníti a távolról tárolt tartalmat. Innen ered az összes eszköz közötti átlátható szinkronizáció.

A probléma a két rendszer közötti átmenetben keletkezik. Pontosan akkor, amikor a régi POP-os helyi emaileket feltölti az IMAP-szerverre.

IMAP APPEND: a parancs, amely mindent megváltoztat

Amikor a levelezőkliens egy helyi üzenetet feltölt egy IMAP-szerverre, az IMAP APPEND parancsot használja. Ez a parancs azt mondja a szervernek: "tárold el ezt az üzenetet abban a mappában".

A szerver megkapja az üzenetet, elmenti, és időbélyeget rendel hozzá. Ez az időbélyeg az INTERNALDATE. Ez az IMAP központi metaadatja: azt jelzi, mikor érkezett az üzenet a szerverre. Ha a kliens nem ad meg explicit dátumot az APPEND parancsban, a szerver az aktuális pillanatot használja.

Más szóval: hiába szerepel az üzenet fejlécében egy 2018-as dátum, ha senki nem mondja a szervernek, hogy "ez az email 2018-ból való", a szerver azt feltételezi, hogy most érkezett, és mai INTERNALDATE-et rendel hozzá.

(Ha Ön valaha is megnézett egy email nyers fejlécét, látta a Date: sort egy tucat Received: sor között. Ez az RFC 2822 által meghatározott Date: mező tartalmazza az eredeti küldési dátumot. Az IMAP INTERNALDATE azonban egy különálló, szerveroldalon tárolt metaadat, amelynek semmi köze magához az üzenet tartalmához.)

Miért más ez, mint egy IMAP-IMAP migráció?

Egy hagyományos IMAP-szerverek közötti migráción (BitTitan, CloudM, imapsync stb.) a probléma kissé eltérően jelentkezik. A migrációs eszköz átmásolja az üzeneteket az egyik szerverről a másikra, és elméletileg az APPEND parancs segítségével át tudja adni az eredeti INTERNALDATE-et a célszervernek. Ott az a baj, hogy egyes eszközök egy Received: fejlécet adnak hozzá a migráció dátumával, ami megzavarja az olyan kliensekben való megjelenítést, mint az Outlook.

Ebben az esetben viszont teljesen helyi adatokból indul ki. Nincs forrásbeli INTERNALDATE, amelyet másolni lehetne. A .pst fájl vagy a Thunderbird-profil saját tulajdonosi formátumban tárolja az üzeneteket, saját belső metaadatokkal. Amikor a levelezőkliens ezeket az üzeneteket újraolvassa az IMAP-szerverre való feltöltéshez, az APPEND parancsot az üzenet tartalmából rekonstruálja. A legtöbb esetben nem ad meg explicit dátumot.

Eredmény: az IMAP-szerver néhány perc alatt több száz vagy ezer üzenetet kap, és mindegyikhez ugyanazt az időintervallumot rendeli hozzá: most.

Ez pontosan az oka annak, hogy a probléma azonnal minden eszközön megjelenik. A telefon, a táblagép, a másodlagos számítógép: mind ugyanahhoz az IMAP-szerverhez csatlakozik, és pontosan ugyanazt látja. Kliensoldalon nincs javítási lehetőség.

Melyik kliens mit jelenít meg, és miért

Nem minden levelezőkliens reagál egyformán. Ezt sok IT-adminisztrátor csak utólag fedezi fel.

Az Outlook (főleg a 2023-2024-es frissítések óta) a szerver INTERNALDATE-ét használja a "Beérkezett" oszlophoz. Tehát a feltöltés dátumát jeleníti meg, nem az eredeti küldési dátumot. Erről az Outlook-specifikus viselkedésről bővebben itt olvashat: Outlook: IMAP migrációs dátum vs. elküldési dátum.

A Gmail / Google Workspace és a Thunderbird valamivel árnyaltabban viselkednek. A Gmail például néha az üzenet fejlécének Date: mezőjét használja a megjelenítéshez, ami azt a benyomást kelti, hogy minden rendben van... egészen addig, amíg dátum szerint nem próbál rendezni, és rá nem jön, hogy a sorrend teljesen véletlenszerű.

Az Apple Mail általában a Date: fejlécből kinyert dátumot jeleníti meg, de a rendezés és a keresés a háttérben az INTERNALDATE-en alapul. Ennek következtében az emailek vizuálisan "helyesnek tűnhetnek", de a rendezési funkció már nem működik megfelelően. Az Apple Mail viselkedéséről részletesebben: Apple Mail: rossz dátumok migráció után.

A jó hír: az eredeti dátum érintetlen

Minden email Date: fejléce, amelyik az eredeti küldési (vagy beérkezési) dátumot tartalmazza, nem sérült. Ott van, az üzenet törzsében. Ezt látja, amikor megnyit egy emailt és megnézi a részleteket.

Az IMAP-szerver csak az INTERNALDATE-et "törte el", ezt az üzeneten kívüli metaadatot. Maga az üzenet érintetlen maradt.

Ez teszi lehetővé a javítást. Ez egyben megmagyarázza azt is, miért maradhat rejtve a probléma egy ideig: az emailek helyesnek tűnnek, ha egyenként nyitja meg őket. Csak akkor válik láthatóvá a hiba, amikor dátum szerint rendezve nézi a beérkező levelek listáját. A 2019-es emailek az elejére kerülnek, mintha most érkeztek volna. Mind ugyanazzal a dátummal.

A méretarány problémája: 3000 email egészen más, mint 3

Talán azt gondolja: "Csak törlöm és újra importálom, ezúttal helyesen." 5-10 tesztüzenettel igen, ez működhet. Egy 8000 üzenetes postafiókkal, egymásba ágyazott mappákkal, nagy méretű mellékletekkel, S/MIME-aláírt emailekkel és 2015-ig visszanyúló levelezési szálakkal... az egészen más történet.

Egy házilagos szkript, amely egy 50 üzenetes tesztkötegen működik, könnyen duplikátumokat hozhat létre, elveszítheti a mellékleteket, vagy összezavarhatja a levelezési szálakat egy éles postafiókban. Az API-kvóták, a hálózati időtúllépések, az atipikus MIME-struktúrájú üzenetek kezelése... ezek mind olyan határesetek, amelyekkel egy nem specializált eszköz nem tud megbirkózni.

És ha valami félúton rosszul sül el? Mentési és visszaállítási mechanizmus nélkül az adatok visszaállíthatatlanul elvesznek.

A problémát jól ismerik a nagy volumenű migrációkat kezelő adminisztrátorok. Megérteni, miért romlottak el a dátumok, az egy dolog. 15 000 emailt helyesen javítani, minden üzenet struktúráját megőrizve, az egészen más. Erről bővebben itt olvashat: Javíthatók-e az email dátumok migráció után?

Hogyan kezeli a Redate.io ezt a konkrét esetet

A Redate.io pontosan erre a helyzetre készült. Az elemzőmotorja azonosítja azokat az emaileket, amelyeknél az INTERNALDATE nem egyezik az üzenet fejléceiben szereplő dátummal, legyen szó POP-IMAP átállásról, IMAP-szerverek közötti migrációról vagy helyi archívum manuális feltöltéséről.

A többlépéses elemzési pipeline megvizsgálja minden egyes üzenet fejlécláncát, ellenőrzi az RFC-megfelelőséget, és rekonstruálja a dátum-metaadatokat az üzenet tartalmának módosítása nélkül: sem a szöveg, sem a mellékletek, sem a MIME-struktúra, sem az esetleges digitális aláírások nem sérülnek. Minden javított emailt egyenként ellenőriz a rendszer, mielőtt jóváhagyja.

Az eredeti üzenetek 30 napig egy látható biztonsági mentési mappában maradnak. Ha valami nem felel meg, visszaállíthatja.

A kezdeti scan ingyenes: a Redate.io elemzi a postafiókot, azonosítja az érintett emaileket, és közli a pontos számot, mielőtt Ön bármit is döntene. Nincs vak elköteleződés.

A Redate.io közvetlenül csatlakozik a postafiókokhoz Google Workspace (domain-delegáció), Microsoft 365 (Azure AD) vagy közvetlen IMAP-kapcsolaton keresztül. Semmilyen helyi telepítés nem szükséges. Nem kell kézzel .pst fájlokat exportálni és kezelni.

Azok az adminisztrátorok, akik több postafiókot kezelnek, és tapasztalatokat keresnek ilyen esetekhez, ezt az írást hasznosnak találhatják: MSP: ügyfél email dátumhibák javítása. A Thunderbird-specifikus viselkedésről, amelynek saját sajátosságai vannak POP/IMAP-átállásnál, pedig itt talál részleteket: Thunderbird: rossz dátum migráció után.

Ha még előtte van: hogyan előzze meg a problémát

Ha még nem töltötte fel a helyi archívumát az IMAP-szerverre, vagy ha a szervezetén belül további POP-fiókok migrációját tervezi, érdemes ezeket szem előtt tartani.

• Ellenőrizze, hogy a levelezőkliense támogatja-e az explicit dátum átadását az APPEND parancsban. A Thunderbird például verziónként eltérő viselkedést mutatott ebben a tekintetben.
• Először végezzen tesztet egy validációs fiókon 50-100 reprezentatív üzenettel: régi emailek, mellékletekkel rendelkezők, aláírt üzenetek. Ellenőrizze a megjelenített dátumokat különböző klienseken.
• Tervezze meg a javítást, mielőtt a végfelhasználók elkezdenek dolgozni a migrált postafiókkal. Az aktív postafiókban lévő dátumok javítása bonyolultabb, mint egy migrálás utáni üres postafiók esetén.
• Dokumentálja az emailek számát migráció előtt és után. Ez az egyetlen módja a csendes adatvesztés észlelésének.

Az átfogó ellenőrzőlistáért, amely lefedi a migráció előtt és után ellenőrzendő összes pontot, tekintse meg ezt a cikket: Email migráció ellenőrzőlista: dátumproblémák megelőzése.

A régi emailei mai dátumot mutatnak POP-ról IMAP-ra való átállás után? Indítson el egy ingyenes scant a Redate.io-n, hogy felmérje a probléma kiterjedését, és helyreállítsa a dátum-metaadatokat az üzenetek tartalmának módosítása nélkül.