cPanel migráció után hibás e-mail-dátumok

A hétfő reggel, amelyre senki sem számít

Épp befejeztük egy cPanel-es megosztott tárhelyen lévő postafiók-rendszer átköltöztetését Google Workspace-be vagy Microsoft 365-be. A migráció simán ment, a postaládák elérhetők, a felhasználók be tudnak lépni. Majd 9:15 körül megérkezik az első support-jegy: „A régi emailjeim mind ugyanazt a dátumot mutatják, a múlt hétvégéét." Aztán a második. Aztán tíz.

Ez nem egyedi hiba. Közvetlen következménye annak, ahogyan a cPanel-ről induló migrációk kezelik (vagy inkább nem kezelik) az emailek dátum-metaadatait.

cPanel, Roundcube, Horde: egy sajátos IMAP-környezet

Egy megosztott cPanel-es tárhelyszolgáltatás egy Linux-szerver, amelyen egy IMAP-szerver (jellemzően Dovecot) fut, Roundcube vagy Horde webmail felülettel. Semmi különös nincs ebben. Csakhogy ennek a környezetnek van néhány sajátossága, amitől a vállalati platformokra való migráció bonyolultabb, mint amilyennek látszik.

Egyrészt a cPanel-es postafiókok évek, néha egy évtized alatt halmozzák fel az e-maileket. Egy ügyfél, akinek a domainje 2013 óta van megosztott tárhelyen, nagyon mély archívummal rendelkezhet. Ez a mennyiség, a migráció végrehajtásának módjával együtt, termékeny táptalajt ad a dátumhibának.

Ráadásul az ilyen migrációkhoz gyakran a natív cPanel-eszközt (a WHM "Migrations" funkcióját), a parancssorból a tárhelyszolgáltató vagy IT-tanácsadó által futtatott imapsync-et, vagy olyan felhasználói szintű megoldásokat használnak, mint a GSMMO a Google Workspace-be történő migráláshoz.

Miért romlanak el a dátumok egy cPanel-migráció után

A probléma megértéséhez két különböző fogalmat kell megérteni: az e-mail Date: fejsorát és az IMAP INTERNALDATE-jét.

A Date: fejsor a nyers üzenettörzsbe kerül beírásra a küldés időpontjában, az RFC 2822 szerint. Azt rögzíti, mikor íródott és küldték el az e-mailt. Ez a fejsor soha nem változik, hacsak valaki szándékosan nem módosítja az üzenetet.

Az INTERNALDATE ezzel szemben egy metaadat, amelyet az IMAP-szerver minden tárolt üzenethez hozzárendel. Elkülönül az üzenet tartalmától magától. Amikor egy e-mail normál módon érkezik meg egy szerverre, az INTERNALDATE-et a Received: fejsorokból vezetik le, vagy a beérkezés időbélyegéből, ha az üzenetet közvetlenül nyújtják be. Ezt az értéket használja az Outlook, a Thunderbird és a legtöbb e-mail-kliens az üzenetek rendezésére.

Egy IMAP-migráció során az üzeneteket az egyik szerverről a másikra másolják. A probléma: a migrációs eszköznek létre kell hoznia minden üzenetet a célszerveren. És sok eszköz esetében az újonnan létrehozott üzenet INTERNALDATE-je a migráció dátumára áll be, nem az eredeti üzenet dátumára. Ráadásul egy, a migráció dátumára bélyegzett Received: fejsor kerül a fejsorlánc elejére, ami még jobban megzavarja azokat az e-mail-klienseket, amelyek ebből számítják ki a megjelenített dátumot.

Az eredmény: egy 2019-es e-mail a Google Workspace-en olyan INTERNALDATE-tel landol, amely a migráció napjára van állítva, és egy tegnapra bélyegzett Received: fejsorral. Az Outlook úgy jeleníti meg a postafiókban, mintha az épp most érkezett volna. A teljes archívum-idővonal tönkremegy.

A WHM / cPanel migrációs eszköz

A WHM-be beépített, cPanel-fiókok másik platformra migrálására szolgáló eszköz ezt a problémát csaknem szisztematikusan előidézi, ha a cél egy külső IMAP-szerver (Google Workspace, Microsoft 365). A Maildir-tartalmat úgy másolja az új szerverre, hogy nem őrzi meg az eredeti INTERNALDATE-et. Minden üzenet a művelet időbélyegét kapja.

imapsync és a cPanel-ből induló kézi migrációk

Az imapsync egy erőteljes eszköz, de az alapértelmezett viselkedése nem mindig őrzi meg a dátumokat. A megfelelő paraméterek (és a megfelelő verzió) nélkül könnyen megeshet, hogy 40 000 üzenetet másol le, és mindegyiket a szkript futtatásának dátumával bélyegzi meg. (Ha már végigment imapsync-naplókon sorról sorra, hogy diagnosztizáljon egy dátumhibát egy 25 000 üzenetes postafiókon, tudja, hogy ez egy olyan tapasztalat, amit nem szeretne megismételni.)

Pontosabban: az imapsync-nek vannak olyan opciói, amelyek próbálják megőrizni a dátumokat, de ezek az opciók a forrás- és célszervertől függően eltérően viselkednek, és hatékonyságuk nem garantált minden cPanel / Dovecot konfigurációnál.

GSMMO és a felhasználói szintű eszközök

A Google Workspace Migration for Microsoft Outlook (GSMMO) az Outlookból való migrálásra készült, nem egy sima IMAP-szerverről. Amikor cPanel-ből migrálnak vele (egy Outlookban beállított IMAP-fiók révén), a dátumok ugyanazt a kezelést kapják: a Google Workspace-en az INTERNALDATE a migráció dátumára áll be. A GSMMO e-mail-dátum problémája egy külön dokumentált téma, ennyire gyakori.

Mely e-mail-klienseket érinti?

A dátumhiba nem minden kliensben jelenik meg egyformán.

Az Outlook a legrosszabbul érintett. Az INTERNALDATE-et (vagy a migráció Received: fejsorát) használja a mappák elsődleges rendezési kulcsaként. Egy rosszul kezelt cPanel-migráció után egy Outlook-postafiók több ezer archivált e-mailt mutathat a migrációs hétvége dátumával. Az imapsync migrációs dátumok javítása az Outlookban egyike a leggyakrabban kért javításoknak.

A Gmail (Google Workspace) az üzenetlistában általában a Date: fejsorból származó dátumot jeleníti meg, de a rendezést egyes esetekben az INTERNALDATE mégis befolyásolhatja. Felhasználók kiszámíthatatlan viselkedésről számolnak be a keresésben és a dátum szerinti rendezésben.

Az Apple Mail és a Thunderbird még következetlenebbül viselkedik, de egyikük sem mentes a problémától, különösen ha egy migrációs Received: fejsor áll a fejsorlánc tetején.

Jó hír: az eredeti dátum még ott van

Ez az a technikai részlet, amely mindent megváltoztat. Az eredeti Date: fejsor a nyers üzenettörzsbe van beírva. A migráció nem érinti azt. Amikor megnyit egy érintett e-mailt, és megnézi a nyers fejsorokat (Gmailben: "Show original", Outlookban: File > Properties), láthatja az eredeti Date:-et sértetlenül, majd egy vagy több Received: fejsort, amelyek közül az első a migráció dátumát viseli.

Ez az információ még ott van. Felhasználható a metaadatok javítására. Pontosan ezt teszi a Redate.io javítómotorja.

Miért kockázatosabb "csak magától megjavítani", mint amilyennek látszik

A kísértés valódi. A probléma egyszerűnek látszik: olvassa el az eredeti dátumot, javítsa ki a metaadatot, és kész. De jelentős szakadék van a mechanizmus megértése és 12 000 éles e-mail javítása között úgy, hogy egyetlen egy se vesszen el.

Néhány valóság, amivel a saját készítésű szkriptek jellemzően nem számolnak:

Egy szkript, amely 50 teszt-e-mailen működik egy fejlesztői környezetben, nem feltétlenül fog helytállni 18 000 üzenettel egy 2011 óta futó cPanel-fiókból örökölt éles postafiókban.

Hogyan javítja a Redate.io a dátumokat egy cPanel-migráció után

A Redate.io közvetlenül csatlakozik a célpostafiókhoz (Google Workspace, Microsoft 365 egyszerű bejelentkezéssel, vagy közvetlen IMAP), és egy ingyenes átvizsgálással kezd, hogy azonosítsa azokat az e-maileket, amelyeknek a dátum-metaadata nem egyezik az eredeti Date: fejsorral.

A többlépcsős elemzési folyamat ezután minta-egyeztetést alkalmaz a Received: fejsor-jelekre, hogy azonosítsa a migrációs eszközök által beszúrtakat (és megkülönböztesse azokat a jogszerű fejsoroktól). A célzott metaadat-javítás az üzenet tartalmának módosítása nélkül történik: a szövegtörzs, a mellékletek, az eredeti fejsorok, minden sértetlen marad. Minden javított e-mailt egyenként ellenőriznek, mielőtt a művelet megerősítésre kerül.

A cPanel-migrációk esetében a motor felismeri a Dovecot-IMAP migrációk és az imapsync-szkriptek jellemző jeleit, beleértve a megosztott tárhelyszolgáltatók között gyakori konfigurációs változatokat is.

Célplatform szerinti útmutatók

A cPanel-migrációja hova érkezett, ezek az útmutatók a pontos lépéseket írják le:

cPanel-ből migrált, és a felhasználók hibás dátumokat látnak? Indítson egy ingyenes átvizsgálást a Redate.io-n, hogy pontosan megtudja, hány e-mailt érint a probléma, mielőtt bármilyen módosítás történne a jóváhagyása nélkül.