A probléma - minden email ugyanazt a dátumot mutatja
Egy IMAP migráció után a felhasználók megnyitják a postafiókjukat, és nyugtalanító látvány fogadja őket: minden egyes email pontosan ugyanazt a dátumot mutatja. Az eredeti küldési vagy fogadási dátum helyett minden üzenet a migráció napját viseli. Évek levelezése, ami látszólag ugyanazon a napon érkezett.
Ez rémálom az IT-adminisztrátorok számára. A hibabejelentések özönlenek, a felhasználók nem találnak semmit dátum alapján, a postafiók kronológiai előzménye lényegében megsemmisült.
Hogyan néz ki az Outlookban
A Microsoft Outlookban a "Fogadva" oszlop minden emailnél a migráció dátumát mutatja. Akár 2018-ban, akár 2023-ban küldték az üzenetet, az Outlook ugyanazt a dátumot jeleníti meg, azt a napot, amikor a migrációs eszköz feldolgozta a postafiókot. A beérkezett üzenetek, az elküldött elemek, minden mappa érintett. Azok a felhasználók, akik a dátum szerinti rendezésre támaszkodnak, teljesen használhatatlannak találják a munkafolyamatukat.
Hogyan néz ki az Apple Mailben
Az Apple Mail macOS-en és iOS-en hasonlóan viselkedik. Az egyes üzenetek mellett megjelenített dátum a migrációs időbélyeget tükrözi az eredeti dátum helyett. Mivel az Apple Mail az IMAP-szerver metaadatait használja a megjelenítési dátumok meghatározásához, ugyanaz az alapvető probléma ugyanazt a látható eredményt produkálja. A beérkezett üzenetek böngészése közben csak azonos dátumok falát látni.
Hogyan néz ki a Gmailben (webes felület)
A Gmail webes felülete kissé eltérő helyzetet mutat. A Gmail webes kliense általában az email saját "Date" fejlécét használja, így az üzenetek a helyes dátummal jelenhetnek meg a Gmailben. De az IMAP INTERNALDATE továbbra is hibás, ami azt jelenti, hogy bármely IMAP-kliens, amely ehhez a Gmail-fiókhoz csatlakozik (Outlook, Thunderbird, Apple Mail), a migráció dátumát jeleníti meg. Így ugyanaz a postafiók az egyik kliensben helyesnek, a másikban hibásnak tűnik. Eléggé zavaró.
Miért történik ez - a technikai ok
A kiváltó ok abban rejlik, ahogyan az IMAP migrációs eszközök kezelik az email-fejléceket, és ahogyan a levelezőkliensek eldöntik, melyik dátumot jelenítsék meg. Ennek megértéséhez röviden át kell tekinteni az IMAP protokollt és a fejlécek szerkezetét.
Hogyan kezelik az IMAP migrációs eszközök a fejléceket
Amikor egy emailt az egyik szerverről a másikra migrálnak, a migrációs eszköz letölti a nyers üzenetet a forrásszerverről, és feltölti a célszerverre az IMAP APPEND paranccsal. A folyamat során az IMAP protokoll megköveteli, hogy a célszerver egy "Received" fejlécet adjon az üzenethez. Ez a fejléc tartalmazza annak az időpontnak az időbélyegét, amikor az üzenetet beillesztették az új szerverre, vagyis a migráció dátumát.
A "Received" fejléc, ami mindent elront
Az email-üzenetek általában több "Received" fejlécet tartalmaznak, amelyeket az eredeti kézbesítés során az üzenetet kezelő levelezőszerverek adtak hozzá. Az olyan kliensek, mint az Outlook, a "fogadás dátumát" a legújabb "Received" fejléc, vagyis a lánc tetején lévő fejléc olvasásával határozzák meg. Amikor egy migrációs eszköz hozzáad egy új "Received" fejlécet a migrációs időbélyeggel, az válik a legújabbá, és a levelezőkliensek ezt a dátumot jelenítik meg az eredeti helyett.
Ez nem az migrációs eszköz hibája, és nem is a levelezőkliensé. Mindkettő helyesen követi az IMAP és email szabványokat. A probléma abból ered, hogy ezeket a szabványokat soha nem tömeges migrációra tervezték, és az IMAP APPEND és a dátum-megjelenítési logika kölcsönhatása ezt a nem kívánt eredményt produkálja.
INTERNALDATE vs Date fejléc
Az IMAP-szerverek két különböző dátumértéket tárolnak minden üzenethez. A "Date" fejléc magának az email-üzenetnek a része, rögzíti, mikor készült és küldte el az üzenetet eredetileg. Az INTERNALDATE az IMAP-szerver által tárolt metaadat, amely azt jelzi, mikor kézbesítették vagy illesztették be az üzenetet az adott szerverre.
Egyes migrációs eszközök megpróbálják megőrizni az eredeti INTERNALDATE értéket az APPEND parancs során. De még ha az INTERNALDATE helyesen van beállítva, a hozzáadott "Received" fejléc továbbra is problémákat okoz azokban a kliensekben, amelyek a "Received" dátumot részesítik előnyben az INTERNALDATE-tel szemben.
Mely migrációs eszközök okozzák ezt a problémát?
Szinte minden IMAP migrációs eszköz okozhatja ezt a problémát. A probléma az IMAP protokollban rejlik, nem egy adott eszközben. Néhányat azonban gyakrabban társítanak a problémával széleskörű használatuk miatt.
BitTitan MigrationWiz
A BitTitan MigrationWiz az MSP-k és IT-tanácsadók által használt legnépszerűbb kereskedelmi migrációs eszközök egyike. A MigrationWiz egy "mx.migrationwiz.com" hivatkozást tartalmazó "Received" fejlécet ad hozzá a migráció során. Ez a fejléc lesz a legújabb a láncban, ami a migrációs dátum megjelenítését okozza az Outlookban és más IMAP-kliensekben. Tekintse meg a részletes útmutatókat a BitTitan dátumok javítása az Outlookban, Microsoft 365, Google Workspace és Exchange Online témakörben.
CloudM Migrate
A CloudM Migrate (korábban Cloud Migrator) széles körben használt a Google Workspace migrációkhoz. A többi eszközhöz hasonlóan a CloudM is hozzáadja a saját "Received" fejlécét az IMAP-beillesztés során. A CloudM-mel migrált emailek a migrációs dátumot mutatják azokban a kliensekben, amelyek a "Received" fejlécet használják. Tekintse meg az útmutatókat a CloudM dátumok javítása a Gmailben, Outlookban, Google Workspace-ben és Microsoft 365-ben.
imapsync
Az imapsync egy népszerű nyílt forráskódú eszköz a Linux-rendszergazdák és tárhelyszolgáltatók körében. Bár az imapsync megpróbálja megőrizni az INTERNALDATE-et, a célszerver az APPEND művelet során mégis hozzáad egy "Received" fejlécet. Az imapsync FAQ-ja elismeri ezt a korlátozást, de nem kínál beépített megoldást a migráció után hozzáadott fejléc eltávolítására. Tekintse meg az útmutatókat az imapsync dátumok javítása az Outlookban, Gmailben, Microsoft 365-ben és Google Workspace-ben.
GSMMO (Google Workspace Migration)
A Google Workspace Migration for Microsoft Outlook (GSMMO) a Google saját eszköze az Exchange-ről vagy Outlook PST-fájlokból a Google Workspace-be történő migrációhoz. A GSMMO ugyanezt a dátumproblémát okozhatja, különösen ha a migráció egy köztes IMAP-lépést tartalmaz. Tekintse meg az útmutatókat a GSMMO dátumok javítása az Outlookban, Gmailben és Apple Mailben.
Exchange Admin Center (natív IMAP import)
A Microsoft Exchange felügyeleti központja tartalmaz egy natív IMAP import funkciót az Exchange Online-ba (Microsoft 365) történő migrációhoz. Ez a beépített migrációs eszköz is "Received" fejléceket ad hozzá az importálás során, ami ugyanazt a dátum-megjelenítési problémát okozza. Tekintse meg az útmutatókat az Exchange IMAP migrációs dátumok javítása az Outlookban és OWA-ban.
Kézi IMAP másolás
Még az emailek kézi másolása IMAP-szerverek között egy olyan klienssel, mint a Thunderbird, is okozhatja ezt a dátumproblémát. Amikor egy levelezőkliens IMAP-on keresztül másol egy üzenetet, a célszerver azt új beillesztésként kezeli, és hozzáadja a saját "Received" fejlécét az aktuális időbélyeggel. Tekintse meg az útmutatókat a kézi IMAP másolás dátumainak javítása az Outlookban, Gmailben, Thunderbirdben és Apple Mailben.
Miért nem működnek a szokásos megoldások
Ezzel a problémával szembesülve a felhasználók és adminisztrátorok általában több megközelítést is kipróbálnak, mielőtt rájönnének, hogy egyikük sem oldja meg igazából a gondot.
"Rendezés küldési dátum szerint" - miért nem elég
A leggyakoribb javaslat az, hogy a levelezőkliensben váltsunk a "fogadási" dátumról a "küldési" dátum szerinti rendezésre. Ez valóban megváltoztatja a megjelenítési sorrendet, de nem javítja az alapul szolgáló adatokat. A keresési eredmények továbbra is a hibás dátumot mutatják. A naptár-integrációk, a megfelelőségi eszközök és a fogadási dátumra támaszkodó automatizált munkafolyamatok továbbra is hibásan működnek. A felhasználóknak pedig minden eszközön és minden mappában meg kell változtatniuk ezt a beállítást.
Újramigráció - drága és kockázatos
Egyes adminisztrátorok fontolóra veszik a migráció újraindítását, abban bízva, hogy a második alkalommal elkerülik a dátumproblémát. Ez a megközelítés drága (500-5000 EUR a postafiók számától függően), időigényes és kockázatos. Egy második migráció ugyanazt a "Received" fejléc problémát okozza, megduplázza az adatvesztés kockázatát, és jelentős leállást igényel. Az újramigráció nem oldja meg a dátumproblémát, hacsak a migrációs eszközt alapvetően nem módosítják.
Kézi fejlécszerkesztés - szerverszintű hozzáférést igényel
Technikailag a javítás a migrációs "Received" fejléc eltávolítását jelenti minden egyes emailből. De ennek kézi végrehajtása közvetlen szerverhozzáférést, az email-fejlécek szerkezetének ismeretét és egyedi szkriptelést igényel. Egy 10 000 emailes postafiók esetében a kézi szerkesztés kivitelezhetetlen és veszélyesen hibára hajlamos. S/MIME aláírású emailek, PGP-titkosított üzenetek, beágyazott MIME-határokkal rendelkező multipart struktúrák, Content-Transfer-Encoding problémák, nem ASCII fejlécek (RFC 2047), túlméretezett mellékletek: ezek mindegyike visszafordíthatatlan adatsérülést okozhat egy egyszerű szkriptnél. Hogyan ellenőrizhető, hogy 10 000 javított email mind sértetlen? Csak egy kifejezetten erre tervezett ellenőrzési rendszerrel.
Az igazi megoldás - az eredeti dátumok visszaállítása
A helyes megközelítés az, hogy azonosítjuk a migrációs nyomokat minden email fejléc-láncában, és célzott javításokat alkalmazunk, amelyek visszaállítják az eredeti kronológiai sorrendet minden levelezőkliensben. Ez nem egy egyszerű fejlécszerkesztés. A folyamat RFC-megfelelőségi validálást, üzenetszerkezet-megőrzést és migrációs aláírás-illesztést foglal magában, ismert eszközprofilok százainak adatbázisa alapján.
Hogyan javítja ezt a Redate.io
A Redate.io csatlakozik a postafiókhoz (Google Workspace, Microsoft 365 vagy bármely IMAP-szerver), és minden emailt elemez a migrációs fejlécek által érintett üzenetek azonosítása érdekében. Az elemzés ingyenes, és pontosan megmutatja, hány email érintett, mielőtt bármilyen fizetésre sor kerülne.
Minden érintett email esetében a Redate.io saját javítómotorja egy többlépcsős elemzési folyamaton vezeti át az üzenetet. A motor aláírás-illesztést alkalmaz ismert migrációs eszközprofilok százain, amelyeket valós email-adatok nagy volumenű feldolgozása alapján épített fel. Kezeli a kódolási problémákat, a multipart struktúrákat, a beágyazott mellékleteket és tucatnyi egyéb esetet, amelyektől egy házilag készített szkript adatokat sértene (nem az a fajta felfedezés, amit hétfő reggel szeretnénk tenni). Minden javított email integritásellenőrzésen megy át a véglegesítés előtt. Az eredeti üzenet egy látható "Redate.io - Originals" mappába kerül (nem törlődik), és 30 napig megőrződik.
Az eredmény? Az emailek az eredeti, helyes dátumokat mutatják minden kliensben. A rendezés újra működik. A postafiók kronológiai előzménye helyreáll.
Gyakran ismételt kérdések
Javíthatók-e a dátumok hónapokkal a migráció után?
Igen. Az eredeti "Date" fejléc az email-üzeneten belül megőrződik, függetlenül attól, mikor történt a migráció. A Redate.io hetekkel, hónapokkal vagy akár évekkel a migráció után is javíthatja a dátumokat. A javítás mindaddig működik, amíg az email eredeti fejlécei sértetlenek.
A dátumjavítás törli az emailjeimet?
Nem. A Redate.io soha nem töröl emaileket. Az eredeti üzenetek egy "Redate.io - Originals" nevű látható mappába kerülnek a postafiókban, ahol 30 napig hozzáférhetők maradnak. Minden javított emailt a rendszer az eredetivel összevetve ellenőriz a folyamat véglegesítése előtt. Ha az ellenőrzés bármely üzenetnél sikertelen, az eredeti sértetlenül marad.
Működik megosztott postafiókokkal?
Igen. A Redate.io működik a Google Workspace és Microsoft 365 megosztott postafiókjaival. Megosztott fiókok esetén rendszergazdai szintű hozzáférés szükséges a csatlakozás engedélyezéséhez. A folyamat megegyezik az egyéni postafiókokéval: elemzés, javítás, ellenőrzés.
Készen áll a helyes dátumok visszaállítására? Indítson egy ingyenes elemzést, és tudja meg, hány email érintett az egyes postafiókokban.