Migrazione cPanel: email mal datate

Il lunedi mattina che fa male

Ha appena terminato la migrazione di un hosting condiviso cPanel verso Google Workspace o Microsoft 365. L'operazione è andata bene, le caselle sono accessibili, gli utenti si connettono. Poi, verso le 9:15, arriva il primo ticket: "Le mie email vecchie mostrano tutte la stessa data, quella del weekend scorso." Poi un secondo. Poi dieci.

Non è un bug isolato. È la conseguenza diretta del modo in cui le migrazioni da cPanel trattano (o meglio, non trattano) i metadati di data delle email.

cPanel, Roundcube, Horde: un contesto IMAP particolare

Un hosting condiviso cPanel è un server Linux che esegue un server IMAP (generalmente Dovecot) con Roundcube o Horde come interfaccia webmail. Niente di esotico. Ma questo contesto ha alcune peculiarità che rendono le migrazioni verso piattaforme enterprise più delicate di quanto sembrino.

Innanzitutto, le caselle cPanel accumulano spesso email per anni, a volte per un decennio. Un cliente che ospitava il proprio dominio su un hosting condiviso dal 2013 può avere archivi molto profondi. Questo volume, combinato con il modo in cui viene eseguita la migrazione, crea un terreno fertile per il problema delle date.

Poi, gli strumenti usati per queste migrazioni sono spesso lo strumento nativo di cPanel (il modulo "Migrations" di WHM), oppure imapsync lanciato da riga di comando dall'hosting provider o dal consulente IT, oppure soluzioni per utenti comuni come GSMMO per migrare verso Google Workspace.

Perché le date risultano corrotte dopo una migrazione cPanel

Per capire il problema, bisogna distinguere due concetti: l'intestazione Date: di un'email e l'INTERNALDATE IMAP.

L'intestazione Date: è scritta nel corpo grezzo del messaggio al momento dell'invio, in conformità con la RFC 2822. Indica quando l'email è stata redatta e inviata. Questa intestazione non cambia mai, salvo manipolazione volontaria del messaggio.

L'INTERNALDATE è invece un metadato che il server IMAP associa a ogni messaggio archiviato. È distinto dal contenuto del messaggio. Quando un'email arriva normalmente su un server, l'INTERNALDATE viene definito a partire dalle intestazioni Received: del messaggio, o alla data di deposito se il messaggio viene consegnato direttamente. È questo valore che Outlook, Thunderbird e la maggior parte dei client email usano per ordinare i messaggi.

Durante una migrazione IMAP, i messaggi vengono copiati da un server all'altro. Il problema è che lo strumento di migrazione deve creare ogni messaggio sul server di destinazione. E per molti strumenti, l'INTERNALDATE del messaggio appena creato corrisponde alla data della migrazione, non alla data originale del messaggio. Allo stesso tempo, un'intestazione Received: con il timestamp della migrazione viene aggiunta in cima alla catena di intestazioni, il che perturba ulteriormente i client email che vi fanno riferimento per calcolare la data da mostrare.

Risultato: un'email del 2019 arriva su Google Workspace con un INTERNALDATE impostato al giorno della migrazione, e un'intestazione Received: datata ieri. Outlook la visualizza nella posta in arrivo come se fosse appena arrivata. L'intera cronologia dell'archivio è distrutta.

Lo strumento di migrazione WHM / cPanel

Lo strumento integrato in WHM per migrare gli account cPanel verso un'altra piattaforma genera questo problema in modo quasi sistematico quando la destinazione è un server IMAP esterno (Google Workspace, Microsoft 365). Copia il contenuto delle Maildir sul nuovo server tramite IMAP APPEND senza preservare l'INTERNALDATE originale. Ogni messaggio riceve quindi il timestamp del momento dell'operazione.

imapsync e le migrazioni manuali da cPanel

imapsync è uno strumento potente, ma il suo comportamento predefinito non preserva sempre le date. Senza i parametri giusti (e la versione corretta), può tranquillamente copiare 40.000 messaggi assegnando a tutti la data di esecuzione dello script. (Del resto, se ha già percorso i log di imapsync riga per riga per diagnosticare un problema di date su una casella di 25.000 messaggi, sa che è un'esperienza che non si vuole ripetere.)

A dire il vero, imapsync dispone di opzioni per tentare di preservare la data, ma queste opzioni interagiscono in modo diverso a seconda dei server di origine e destinazione, e la loro efficacia non è garantita su tutte le configurazioni cPanel / Dovecot.

GSMMO e gli strumenti per utenti comuni

Google Workspace Migration for Microsoft Outlook (GSMMO) è pensato per migrare da Outlook, non da un server IMAP nudo. Quando viene usato per migrare da cPanel (tramite un account IMAP configurato in Outlook), le date subiscono lo stesso trattamento: l'INTERNALDATE su Google Workspace viene impostato alla data di migrazione. Il problema GSMMO e le date delle email è peraltro documentato separatamente, tanta è la sua diffusione.

Quali client email sono interessati?

La corruzione delle date non si manifesta allo stesso modo a seconda del client utilizzato.

Outlook è il client più colpito. Usa l'INTERNALDATE (o l'intestazione Received: di migrazione) come criterio di ordinamento principale per le cartelle. Dopo una migrazione cPanel mal gestita, una casella in Outlook può mostrare migliaia di email archiviate con la data del weekend di migrazione. La correzione delle date imapsync in Outlook è una delle correzioni più richieste.

Gmail (Google Workspace) mostra generalmente la data ricavata dall'intestazione Date: nell'elenco delle email, ma l'ordinamento può comunque essere influenzato dall'INTERNALDATE in certi casi. Gli utenti segnalano comportamenti erratici nella ricerca e nell'ordinamento per data.

Apple Mail e Thunderbird hanno comportamenti più sfumati, ma né l'uno né l'altro sono immuni al problema, soprattutto quando l'intestazione Received: di migrazione è presente in testa alla catena.

Buona notizia: la data originale è ancora lì

È il dettaglio tecnico che cambia tutto. L'intestazione Date: originale del messaggio è scritta nel corpo grezzo dell'email. La migrazione non la tocca. Aprendo un'email interessata e guardando le intestazioni grezze (in Gmail: "Mostra originale", in Outlook: File > Proprietà), si vede il Date: originale intatto, seguito da una o più intestazioni Received: di cui la prima porta la data di migrazione.

Questa informazione è sempre presente. Può essere sfruttata per correggere i metadati. È esattamente quello che fa il motore di correzione di Redate.io.

Perché "correggere da soli" è più rischioso di quanto sembri

La tentazione è forte. Il problema sembra semplice: leggere la data originale, correggere i metadati, passare al successivo. Ma tra capire il meccanismo e correggere 12.000 email in produzione senza perderne una sola, c'è un divario considerevole.

Alcune realtà che gli script fatti in casa generalmente non anticipano:

Email firmate S/MIME o cifrate con PGP: qualsiasi modifica alla struttura del messaggio invalida la firma crittografica. Un'email che superava la verifica della firma prima della correzione non la supera più dopo. Gli utenti soggetti a conformità normativa (studi legali, settore finanziario, sanità) scoprono questo problema nel momento peggiore.
Intestazioni non-ASCII e codifica RFC 2047: le caselle cPanel accumulano anni di email provenienti da client molto diversi. Alcune intestazioni contengono caratteri codificati secondo RFC 2047. Uno script mal scritto che ricostruisce le intestazioni può corrompere queste codifiche in modo invisibile.
Strutture MIME annidate: un'email con tre allegati e un corpo HTML alternativo ha una struttura multipart complessa. Il minimo errore sui boundary MIME rende il messaggio illeggibile, o peggio: gli allegati spariscono senza alcun messaggio di errore.
Quote API e rate limiting: Google Workspace e Microsoft 365 impongono limiti severi sul numero di operazioni IMAP al minuto. Uno script che non implementa correttamente l'exponential backoff genera errori 429 alle 3 di notte, e ci si sveglia con una migrazione a metà di cui non si sa esattamente dove si è fermata.
Rollback impossibile: se qualcosa va storto a metà percorso, a quale stato si ritorna? Gli originali sono ancora lì? Ci sono duplicati? Redate.io conserva gli originali in una cartella di backup visibile per 30 giorni, precisamente per non trovarsi mai in questa situazione.

Uno script che funziona su 50 email di test in un ambiente di sviluppo non funzionerà necessariamente su 18.000 messaggi di una casella di produzione ereditata da un hosting cPanel dal 2011.

Come Redate.io corregge le date dopo migrazione cPanel

Redate.io si connette direttamente alla casella di destinazione (Google Workspace tramite delega di dominio, Microsoft 365 tramite Azure AD, o server IMAP diretto) e inizia con una scansione gratuita per identificare le email i cui metadati di data sono incoerenti con l'intestazione Date: originale.

Il pipeline di analisi multi-fase applica poi un pattern matching sulle firme delle intestazioni Received: per identificare quelle introdotte dagli strumenti di migrazione (distinguendole da quelle legittime). La correzione mirata dei metadati avviene senza alterare il contenuto del messaggio: testo, allegati, intestazioni originali, tutto resta intatto. Ogni email corretta viene verificata singolarmente prima che l'operazione venga convalidata.

Per le migrazioni da cPanel in particolare, il motore riconosce le firme tipiche delle migrazioni Dovecot-verso-IMAP e degli script imapsync, incluse le varianti di configurazione comuni presso gli hosting condivisi italiani ed europei.

Guide specifiche per la piattaforma di destinazione

A seconda della piattaforma di destinazione della migrazione cPanel, le guide seguenti descrivono i passaggi precisi:

Ha migrato da cPanel e i suoi utenti vedono date errate? Avvii una scansione gratuita su Redate.io per identificare esattamente quante email sono interessate, senza alcuna modifica prima del suo consenso.

Email mal datate dopo migrazione cPanel / Roundcube