Correggere date imapsync

La promessa di --syncinternaldates (e dove si ferma)

Ha eseguito il comando imapsync. Ha incluso --syncinternaldates perché ha letto la documentazione ed è scrupoloso così. La migrazione finisce, il log dice tutto trasferito, zero errori. Poi apre la casella di posta in Outlook e ogni email mostra la data di ieri.

Questa è una delle frustrazioni più comuni con imapsync, e confonde gli amministratori di sistema almeno dal 2017. Il flag --syncinternaldates dovrebbe preservare l'INTERNALDATE IMAP durante la migrazione. E infatti lo fa: assegna a ogni copia la data interna che il server di origine possiede. È esattamente lì che si trova la trappola.

imapsync è uno strumento open-source in Perl scritto da Gilles Lamiral, ed è genuinamente buono in quello che fa. Gestisce trasferimenti di caselle di posta IMAP-a-IMAP con un livello di affidabilità che la maggior parte degli strumenti commerciali invidia. Ma imapsync può copiare solo le date che trova, ed è lì che le cose si complicano.

Come funzionano realmente le date IMAP

Ci sono tre "date" diverse coinvolte in ogni email, e la maggior parte delle persone (inclusi alcuni amministratori IT) le confonde:

L'header Date: (RFC 2822) - la data che il client email del mittente ha timbrato quando il messaggio è stato composto. Vive nel corpo del messaggio e non viene mai modificato dai server di posta.
Header Received: - ogni server di posta che gestisce il messaggio ne aggiunge uno con il proprio timestamp. Formano una catena dal mittente al destinatario. L'header Received più in alto (più recente) è ciò che alcuni client email usano per la visualizzazione.
INTERNALDATE - un timestamp lato server IMAP che controlla come i messaggi vengono ordinati nella casella. Viene impostato quando il messaggio viene memorizzato per la prima volta tramite IMAP APPEND.

Quando imapsync migra un messaggio, lo legge dal server di origine (incluso il suo INTERNALDATE) e lo scrive sul server di destinazione usando IMAP APPEND. Il flag --syncinternaldates dice a imapsync di passare l'INTERNALDATE di origine al server di destinazione durante l'APPEND.

Ecco la buona notizia: Microsoft 365, Outlook.com e Gmail mantengono la data che ricevono. Quindi, quando le date risultano sbagliate, il problema è altrove.

Perché le date possono comunque risultare sbagliate

La specifica IMAP (RFC 3501) dice che se viene fornita una data-ora con il comando APPEND, il server DOVREBBE usarla. "DOVREBBE" in linguaggio RFC significa "fatelo a meno che non abbiate una buona ragione per non farlo". Microsoft 365, Outlook.com e Gmail lo fanno: una copia che porta la sua data originale la mantiene.

Quello che imapsync trasmette, però, è la data che il server di ORIGINE possiede per ogni messaggio, non la data in cui l'email è stata inviata. Su una casella sana le due coincidono. Su una casella già migrata una volta o ripristinata da un backup, l'origine può contenere la data di quell'operazione precedente, e imapsync la copia tale e quale.

Gmail è un caso a parte solo quando la copia passa attraverso l'API di importazione propria di Gmail invece che via IMAP: quell'API aggiunge una riga Received: datata il giorno della copia, e Outlook può mostrare quella data. imapsync parla IMAP, quindi non ne è interessato.

Dovecot e Cyrus, i due server IMAP open-source più comuni, mantengono anch'essi la data ricevuta con l'APPEND. Quindi, qualunque sia la destinazione, la domanda è sempre la stessa: quale data possedeva l'origine?

Errori comuni della riga di comando imapsync che rompono le date

Oltre alle date di origine, gli amministratori spesso inciampano nelle opzioni della riga di comando di imapsync, o ne incolpano le sbagliate. Ecco gli errori che vedo più spesso:

Copiare da un'origine le cui date erano già sbagliate

--syncinternaldates è attivo per default: imapsync assegna a ogni copia la data interna che il server di origine possiede (la sua documentazione: "Sets the internal dates on host2 as the same as host1"). Se la casella di origine è essa stessa il risultato di una migrazione precedente o di un ripristino, le sue date interne potrebbero già essere quelle di quell'operazione, e imapsync copia fedelmente la data sbagliata. È la causa più comune, e la più facile da perdere, perché il log mostra due date identiche.

Usare --syncinternaldates con --addheader

Alcune guide raccomandano di usare --addheader per iniettare un header personalizzato durante la migrazione. Aggiungere un header modifica il messaggio (una riga in più in testa) ma non la data che imapsync trasmette, quindi non spiega date sbagliate. La copia semplicemente non è più identica all'originale, il che conta se si confrontano i due.

Confondere --minage e --maxage con la preservazione delle date

I flag --minage e --maxage filtrano quali messaggi migrare in base alla loro età. Non influenzano come le date vengono gestite alla destinazione. Ho visto amministratori passare ore a regolare questi flag pensando che avrebbero risolto il problema delle date. Non lo faranno.

Incolpare il TLS per date spostate

Su TLS (--ssl1, --ssl2), la configurazione delle connessioni aggiunge latenza, e su una migrazione grande (50.000+ messaggi) questa arriva ad accumulare ore. Non tocca le date: ogni copia porta la data che imapsync trasmette, indipendentemente dall'ora in cui arriva davvero.

Leggere i log di imapsync: cosa dice davvero l'output

imapsync produce log dettagliati, il che è ottimo. Ma l'output del log può essere fuorviante per quanto riguarda le date.

Una tipica riga di trasferimento riuscito appare così:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Le due date corrispondono. Microsoft 365, Outlook.com e Gmail mantengono tutti la data che ricevono. Ma due date identiche dimostrano solo che la copia è fedele all'ORIGINE: se la data di origine era già sbagliata, entrambe le colonne mostrano la stessa data sbagliata.

Vuole verificare cosa è realmente successo? Dopo la migrazione, si colleghi alla destinazione con un client IMAP e verifichi l'INTERNALDATE direttamente:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Se la data restituita non è la data in cui l'email è stata inviata, guardi lo stesso messaggio sull'origine: troverà lì la stessa data sbagliata. Il log non Le ha mentito, ha copiato quello che ha ricevuto.

Questo è uno degli aspetti più frustranti del debug dei problemi di date: un file di log pulito, due date identiche, e comunque la data sbagliata in Outlook, perché l'errore era già presente prima che imapsync venisse eseguito.

Migrazioni imapsync su larga scala: dove i problemi di date si moltiplicano

Una migrazione di singola casella con imapsync è fastidiosa quando le date si rompono. Ma gli MSP e i reparti IT che eseguono imapsync su centinaia di caselle affrontano una scala di problema completamente diversa.

Consideri uno scenario tipico di migrazione aziendale. Si stanno spostando 200 caselle di posta da un server Zimbra a Microsoft 365. Si scrive uno script wrapper che scorre un CSV di utenti, chiamando imapsync per ciascuno. La migrazione gira durante il weekend. Lunedì mattina, ci sono 200 caselle con date rotte e circa 1,2 milioni di email in totale che mostrano il timestamp di migrazione.

Si può rieseguire imapsync per correggerlo? Tecnicamente sì, ma imapsync salterà i messaggi che esistono già alla destinazione (è progettato per essere idempotente). Servirebbe --delete2 per rimuovere i messaggi di destinazione e ritrasferirli, il che è rischioso su una casella di produzione. E se il problema erano le date di origine, una seconda esecuzione copia di nuovo le stesse date sbagliate.

Alcuni amministratori provano un approccio ibrido: prima imapsync con --dry per testare, poi la migrazione vera. Ma --dry simula solo il trasferimento: mostra le date che imapsync trasmetterebbe, non se sono le date in cui le email sono state inviate. Niente avvisa che le date di origine sono già sbagliate.

Correzioni fai-da-te e i loro limiti

Se si cerca nei forum e nelle mailing list (la lista imapsync-devel su SourceForge è ancora attiva a inizio 2026), si trovano suggerimenti che vanno dal creativo al pericoloso.

Alcuni suggeriscono di usare un one-liner Perl per modificare l'INTERNALDATE sul server di destinazione direttamente. Altri raccomandano di esportare tutti i messaggi in formato mbox, manipolare le date e reimportare. Alcuni hanno scritto script Python che usano imaplib per recuperare, modificare e reinserire messaggi.

Tutti questi approcci condividono gli stessi problemi fondamentali. Come gestire messaggi firmati S/MIME senza rompere la firma? E le strutture MIME multipart con boundary annidati? Header non-ASCII codificati con RFC 2047? Messaggi crittografati PGP dove non si può nemmeno ispezionare il contenuto? Uno script che gestisce 50 messaggi di test in un ambiente di sviluppo si bloccherà sui casi limite di una casella di produzione di 30.000 messaggi.

E la domanda più grande che nessuno pone finché non è troppo tardi: come si verifica che ogni singolo messaggio modificato è ancora intatto? Che gli allegati non si sono corrotti, che il threading funziona ancora, che il foglio di calcolo da 85 MB che qualcuno ha inviato nel 2020 è sopravvissuto alla manipolazione?

(Se ha mai provato a parsare header di email grezzi in Perl, sa che non è esattamente un'attività rilassante per il pomeriggio.)

Come Redate.io corregge i problemi di date imapsync

L'header Date: originale è sempre intatto dopo una migrazione imapsync. imapsync trasferisce il messaggio grezzo fedelmente; la data sbagliata si trova nei metadati che la copia ha ricevuto, non nel messaggio. Quell'header originale è ciò che rende possibile la correzione.

Redate.io si connette direttamente alla casella di posta (Google Workspace, Microsoft 365 o qualsiasi server IMAP), scansiona alla ricerca di email con anomalie di data e applica correzione mirata dei metadati attraverso una pipeline proprietaria di analisi della catena di header e ricostruzione delle date. Non ha bisogno di sapere quale strumento ha effettuato la migrazione: individua le email la cui data visualizzata non corrisponde alla loro data originale.

Ogni email corretta viene verificata individualmente: integrità del messaggio, preservazione degli allegati, posizionamento nelle cartelle, threading, etichette. Gli originali sono conservati in una cartella di backup visibile Redate.io - Originals finché non li elimina Lei stesso. Se qualcosa non va, l'annullamento è a un clic di distanza.

La scansione gratuita si collega alla casella, identifica ogni email con un'anomalia di data e riporta il conteggio esatto e il costo. Nessuna carta di credito richiesta, nessun software da installare. Per i dettagli della piattaforma:

Redate.io funziona anche per migrazioni avvenute mesi o anni fa. L'header Date: non scade, e nemmeno la possibilità di correggere.

Migrato con imapsync e bloccato con date sbagliate? Esegua una scansione gratuita per vedere esattamente quante email sono interessate.

imapsync: date non conservate? Come correggerle