eM Client: hibás dátumok PST vagy Thunderbird import után

A tünet: minden emailen ugyanaz a dátum szerepel

Befejezte a PST-import folyamatát eM Clientben, vagy átköltözött Thunderbirdről az új postafiókjába. Az import látszólag hibátlanul ment végig. De a beérkező levelek mappájában valami rögtön szemet szúr: több száz, olykor több ezer email ugyanazt a dátumot mutatja, mégpedig az import napját. Egy 2019-es üzenet mintha tegnap érkezett volna. Egy három éve aláírt szerződés úgy jelenik meg, mintha most futott volna be.

Az első természetes reakció az eM Clientet hibáztatni. Rossz beállítás, rossz rendezési oszlop, megjelenítési hiba... Az ember turkál a beállítások között. Átkapcsol a "Beérkezés dátuma" és az "Elküldés dátuma" között. Semmi sem változik. Pontosabban: valami változik, de az alapvető problémát nem oldja meg.

Azért, mert a probléma nem az eM Clientben van. A szerver metaadataiban van.

A valódi ok: az IMAP INTERNALDATE felülíródik az import során

A jelenség megértéséhez egy szinttel mélyebbre kell menni, és meg kell nézni, hogyan tárolja az IMAP protokoll az emaileket.

Minden üzenetnek egy IMAP szerveren kétféle dátuma van:

• A Date: fejléc (az RFC 2822 szerint): ezt az elküldő írta az üzenetbe küldéskor. Maga az üzenet belsejébe van ágyazva, elméletileg nem módosítható.
• Az INTERNALDATE: egy szerveroldali metaadat, az üzenettől független, amely azt jelzi, mikor helyezték el a postafiókban. Ez az az érték, amelyet a levelezőprogramok elsősorban a rendezéshez és a megjelenítéshez használnak.

PST-import vagy Thunderbird-migráció során az importáló eszköz (legyen az eM Client beépített modulja, harmadik féltől származó program, vagy kézi IMAP-másolás) a célszerverre teszi fel az üzeneteket. Ha az eszköz nem tartja meg kifejezetten az eredeti INTERNALDATE értéket a feltöltéskor, a szerver automatikusan az aktuális időpontot rendeli hozzá, vagyis az import dátumát és időpontját.

Eredmény: 8000, 2017 óta archivált email, mind a migrációs pillanatban "fogadottként" megjelölve.

(Ha egyébként már próbálta a nyers fejléceket az eM Client Forrás megtekintése funkciójával olvasni, azt láthatta, hogy az eredeti Date: fejléc ott van, érintetlenül. Ez pontosan azt jelzi, hogy a probléma a szerver INTERNALDATE értékéből ered, nem magából az üzenetből.)

Miért nem segít a rendezési oszlop átállítása

A félreértés abból fakad, hogy kevesen tudnak egy fontos különbségről. Az eM Clientben, akárcsak Outlookban vagy Thunderbirdben, általában két dátumoszlop létezik:

• "Beérkezés dátuma" (vagy "Érkezési dátum"): a szerver INTERNALDATE értékén alapul.
• "Dátum" vagy "Elküldés dátuma": az üzenet Date: fejlécén alapul.

Sok rendszergazda rátalál erre és azt gondolja, megtalálta a megoldást: átkapcsol az "Elküldés dátumára", és a probléma vizuálisan eltűnik az eM Clientben. Ez azonban nem teljesen helytálló.

Pontosabban szólva: még ha az eM Clientben elküldési dátum szerint is rendez, a probléma minden más kliensnél és minden más interfésznél megmarad, amelyek ugyanahhoz a postafiókhoz férnek hozzá. Ha a felhasználók OWA-ból, irodai Outlookból, mobilon a Gmail alkalmazásból, vagy bármilyen IMAP-on beállított kliensből olvassák az emailjeiket, az import dátumát fogják látni. Az eM Client rendezési beállítása csak az eM Clientre vonatkozik, és nem változtatja meg a szerveren tárolt metaadatokat.

Emellett a Microsoft 365 és a Google Workspace natív webes nézete INTERNALDATE szerint rendez. Ezt a viselkedést nem lehet megváltoztatni az ügyfélprogramból.

Az elküldési dátum szerinti rendezés nem megoldás. Egy tapasz, amely elfedi a valódi problémát anélkül, hogy orvosolná.

A PST-import különleges esete

A PST-fájlok importja külön figyelmet érdemel. A PST (Personal Storage Table) egy Microsoft-tulajdonú formátum, amely emaileket, névjegyeket és naptárelemeket tárol helyben. Az eM Clientbe importált PST esetében két forgatókönyv lehetséges:

• Helyi import IMAP-fiókba: az eM Client beolvassa a PST-t, és az üzeneteket a célszerverre tölti fel. Ha a feltöltési dátum nem marad meg, az INTERNALDATE felülíródik. Ez a leggyakoribb eset, és ez az, ahol a dátumok megsérülnek.
• Import helyi mappába: az üzenetek a gépen maradnak, szerveren kívül. Ebben a kontextusban az INTERNALDATE nem létezik, és az eM Client az üzenet Date: fejlécét jelenítheti meg. Kevesebb dátumgond, de kevesebb praktikus hasznosság is.

Thunderbird esetén a helyzet hasonló. Akár az eM Client beépített importálóját (amely a Thunderbird-profilokat olvassa), akár mbox-mappák IMAP-on keresztüli másolását használja, az üzenetek a szerverre kerülnek anélkül, hogy az INTERNALDATE megőrzése garantált lenne. Egy szerver, amely explicit dátumutasítás nélkül kap üzenetet az INTERNALDATE-re vonatkozóan, következetesen a fogadás pillanatát rögzíti időbélyegként.

Melyik platformot érinti a probléma?

A probléma ugyanaz bármely célplatformon, mert ez az IMAP protokoll szabványos viselkedése:

• Microsoft 365 / Exchange Online: az INTERNALDATE felülíródik minden olyan importnál, amely nem használja az IMAP APPEND parancsot explicit dátumparaméterrel. Ugyanez vonatkozik a helyszíni Exchange-ről való migrációra is.
• Google Workspace: ugyanez a viselkedés. Az eM Clienten vagy harmadik féltől származó eszközökön keresztül importált emailek az import dátumát mutatják Gmailben és az adminisztrációs felületen is.
• Hagyományos IMAP-tárhelyek (OVH, Infomaniak, Ionos, Rackhost stb.): nincs különleges dátumkezelés APPEND útján fogadott üzenetnél. Az INTERNALDATE a feltöltés dátuma lesz.

Egy ügyfél megkeresett minket, miután nagyjából száz postafiókot migráltott Exchange 2013-ról Microsoft 365-re, az eM Clientet használva átmeneti eszközként egyes VIP-fiókoknál. Eredmény: a MigrationWizen keresztül rendesen migrált postafiókokban minden rendben volt, de az eM Clienten átment fiókok mindegyikén az import dátuma szerepelt. Mondanom sem kell, az érintett felhasználók nem értékelték.

Miért nem oldja meg ezt egy házi szkript könnyen

Technikai szempontból valaki, aki érti az IMAP protokollt, gondolhat arra, hogy írjon egy szkriptet az INTERNALDATE értékek korrekciójára. Az eredeti Date: fejléc ott van, érintetlenül minden üzenetben. Csak be kell olvasni és ennek megfelelően rekonstruálni a szerver metaadatait, nem igaz?

Elméletben igen. A gyakorlatban ez egy aknáktól teli terep.

Először is, az élcasetek gyorsan szaporodnak egy éles postafiókban. Az S/MIME-mel digitálisan aláírt üzenetek különösen érzékenyek a strukturális manipulációra. Ugyanez vonatkozik a PGP-vel titkosított üzenetekre. A nagy mellékletű, nem szabványos MIME-határolókkal vagy szokatlan Content-Transfer-Encoding kódolással rendelkező emailek csendben megsérülhetnek, ha a kezelés nem elég körültekintő. Egy 50 tesztemailnél működő szkript nem fog megbízhatóan teljesíteni egy 20 000 üzenetes, 6 év előzménnyel rendelkező postafiókban.

Aztán ott van az API-kvóta kezelése. A Microsoft 365-ön a Graph API vagy az EWS sebességkorlátai hajnali 3-kor, egy 8000 üzenetes korrekciós batch közben, kezelhetők. De nem kezelhetők maguktól. Egy felügyelet nélküli szkript, amely 429-es "Too Many Requests" hibába ütközik a 3741-es üzenetnél, talán folytatja, talán nem. És nem feltétlenül lehet tudni, mely üzenetek lettek feldolgozva.

A legfontosabb kérdés: hogyan ellenőrzi, hogy minden javított email sértetlen maradt a feldolgozás után? Egy házi szkriptnek általában nincs egyedi ellenőrzési mechanizmusa. A Redate.io ezt automatikusan elvégzi, minden egyes üzenethez.

Dátumok javítása a forrásnál a Redate.io-val

A Redate.io ott támadja meg a problémát, ahol az valóban van: a szerver metaadatainak szintjén, nem a levelezőprogram szintjén.

A folyamat egy ingyenes vizsgálati fázissal kezdődik. A Redate.io kapcsolódik az érintett postafiókhoz (Microsoft 365 Azure AD-n keresztül, Google Workspace domainszintű delegáción át, vagy közvetlen IMAP-on hagyományos tárhelyszolgáltatóknál), és azonosítja azokat az emaileket, amelyek dátum-metaadatai ellentmondanak az üzenet tartalmának. Az eredményeket még a fizetés előtt látja.

A javítás egy saját fejlesztésű motort alkalmaz, amely elemzi az egyes üzenetek teljes fejlécláncolását, mintaillesztést végez több száz ismert importeszköz-szignatúrán (beleértve az eM Client, a Thunderbird és a PST-importok specifikus viselkedésmintáit), és célzottan rekonstruálja a dátum-metaadatokat anélkül, hogy az üzenet tartalmát, mellékleteit vagy MIME-struktúráját megváltoztatná.

Minden javított emailt egyenként ellenőriz. Az eredetiek egy látható biztonsági mentési mappában maradnak 30 napig, amit egy házi szkript alapértelmezés szerint soha nem tesz meg.

Az árazás egyszerű: egyszeri fizetés postafiókönként, a javítandó emailek mennyisége alapján. Sem előfizetés, sem visszatérő díj. A részletekért látogassa meg a kezdőlapot.

A következő migrációhoz: mit kell ellenőrizni

Ha tervez egy migrációt, és előre szeretné elkerülni ezt a problémát, az ellenőrzési pont egyszerű: a használt eszköz explicit módon megőrzi-e az INTERNALDATE értéket az üzenetek célszerverre történő feltöltésekor?

PST Microsoft 365-be importálásakor a Microsoft által tanúsított eszközök (mint a MigrationWiz natív módokban, vagy az Exchange Online migrációs eszköze) általában kezelik ezt a megőrzést. Kézi importoknál eM Clienten vagy Thunderbirden keresztül ez ritkán van így. Az éles postafiókokra indított import előtt mindenképpen ellenőrizze az eszköz dokumentációját.

Egy jó email-migrációs ellenőrzőlista mindig tartalmaz egy migrációt követő dátumellenőrzést néhány postafiók mintáján. Ha mélyebben bele szeretne ásni a témába, az email-migrációs ellenőrzőlistánk részletesen foglalkozik ezzel a kérdéssel.

Az ügyfelek migrációit rendszeresen végző adminok számára az MSP-knek szóló dátumjavítási cikk és az IMAP INTERNALDATE működéséről szóló írás teljesebb képet ad a problémáról.

Sérültek az email dátumai egy eM Client-import után? Indítson ingyenes vizsgálatot a Redate.io-n, és mérje fel a probléma mértékét, mielőtt dönt a következő lépésről.