Correggere date imapsync

La promessa di --syncinternaldates (e perche non regge)

Ha eseguito il comando imapsync. Ha incluso --syncinternaldates perche ha letto la documentazione ed e scrupoloso cosi. 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 e una delle frustrazioni piu comuni con imapsync, e confonde gli amministratori di sistema almeno dal 2017. Il flag --syncinternaldates dovrebbe preservare l'INTERNALDATE IMAP durante la migrazione. E tecnicamente, ci prova. Ma "ci prova" sta facendo un lavoro pesante in quella frase.

imapsync e uno strumento open-source in Perl scritto da Gilles Lamiral, ed e genuinamente buono in quello che fa. Gestisce trasferimenti di caselle di posta IMAP-a-IMAP con un livello di affidabilita che la maggior parte degli strumenti commerciali invidia. Ma la preservazione delle date non e interamente nelle mani di imapsync, ed e li 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 e 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 piu in alto (piu recente) e cio 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 il problema: il server di destinazione non e obbligato a rispettare quella data.

Perche i server di destinazione ignorano l'INTERNALDATE

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". Diverse piattaforme email importanti hanno deciso di avere una buona ragione.

Microsoft 365 e il piu grande trasgressore. Quando un messaggio arriva via IMAP APPEND, la pipeline di trasporto di Exchange appone un nuovo header Received con la data corrente, poi imposta l'INTERNALDATE basandosi su quel timestamp di consegna. Non importa quale data abbia richiesto imapsync. Il server M365 la sovrascrive.

Google Workspace (Gmail) si comporta diversamente ma puo ugualmente causare problemi. L'implementazione IMAP di Gmail rispetta l'INTERNALDATE dall'APPEND nella maggior parte dei casi, ma aggiunge il proprio header Received. Se il client email che legge la casella priorizza gli header Received rispetto all'INTERNALDATE per la visualizzazione (e Outlook fa esattamente questo), le date appaiono comunque sbagliate.

Dovecot e Cyrus, i due server IMAP open-source piu comuni, generalmente rispettano l'INTERNALDATE dall'APPEND. Quindi le migrazioni imapsync tra due server Dovecot di solito preservano le date correttamente. I problemi iniziano quando la destinazione e una piattaforma ospitata con la propria elaborazione di trasporto.

Errori comuni della riga di comando imapsync che rompono le date

Anche quando il server di destinazione coopererebbe, gli amministratori spesso inciampano nelle opzioni della riga di comando di imapsync. Ecco gli errori che vedo piu spesso:

Dimenticare --syncinternaldates del tutto

Il flag non e attivato per default. Se si esegue un imapsync --host1 source --host2 dest --user1 user --user2 user base senza di esso, imapsync non tenta affatto di preservare le date. Il server di destinazione usa il timestamp corrente per ogni messaggio. E la causa piu comune, e la piu facile da perdere perche imapsync non avvisa.

Usare --syncinternaldates con --addheader

Alcune guide raccomandano di usare --addheader per iniettare un header personalizzato durante la migrazione. Se si aggiungono header, si sta modificando il messaggio, il che puo indurre il server di destinazione a trattarlo come un messaggio "nuovo" e timbrarlo di conseguenza. L'interazione tra questi due flag e scarsamente documentata.

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

I flag --minage e --maxage filtrano quali messaggi migrare in base alla loro eta. 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.

Deriva di timestamp per negoziazione SSL

Quando si migra su TLS con --ssl1 e --ssl2, la configurazione della connessione aggiunge latenza. Nelle migrazioni grandi (50.000+ messaggi), questa latenza si accumula. Non cambia le date di giorni, ma puo far si che messaggi inviati a pochi minuti di distanza arrivino con timestamp identici alla destinazione, perdendo il loro ordine relativo.

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

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

Una tipica riga di trasferimento riuscito appare cosi:

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. Significa che imapsync ha inviato il corretto INTERNALDATE alla destinazione. Ma non significa che il server di destinazione abbia effettivamente memorizzato quella data. imapsync riporta quello che ha richiesto, non quello che il server ha accettato.

Vuole verificare cosa e 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 e la data di migrazione invece del 2019-01-15, il server di destinazione ha ignorato la richiesta di imapsync. Il log Le ha mentito (beh, Le ha detto cosa ha chiesto, non cosa ha ottenuto).

Questo divario tra cio che imapsync riporta e cio che realmente accade e uno degli aspetti piu frustranti del debug dei problemi di date. Si puo fissare un file di log pulito per ore senza mai rendersi conto che le date sono sbagliate dall'altra parte.

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

Una migrazione di singola casella con imapsync e 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. Lunedi mattina, ci sono 200 caselle con date rotte e circa 1,2 milioni di email in totale che mostrano il timestamp di migrazione.

Si puo rieseguire imapsync con --syncinternaldates se lo si e dimenticato la prima volta? Tecnicamente si, ma imapsync saltera i messaggi che esistono gia alla destinazione (e progettato per essere idempotente). Servirebbe --delete2 per rimuovere i messaggi di destinazione e ritrasferirli, il che e rischioso su una casella di produzione. E anche cosi, se il server di destinazione ignora l'INTERNALDATE, si torna al punto di partenza.

Alcuni amministratori provano un approccio ibrido: prima imapsync con --dry per testare, poi la migrazione vera. Ma --dry non testa cosa fa il server di destinazione con l'INTERNALDATE. Simula solo il trasferimento. Il problema delle date e invisibile finche i messaggi non vengono effettivamente scritti alla destinazione.

Correzioni fai-da-te e i loro limiti

Se si cerca nei forum e nelle mailing list (la lista imapsync-devel su SourceForge e 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 puo nemmeno ispezionare il contenuto? Uno script che gestisce 50 messaggi di test in un ambiente di sviluppo si blocchera sui casi limite di una casella di produzione di 30.000 messaggi.

E la domanda piu grande che nessuno pone finche non e troppo tardi: come si verifica che ogni singolo messaggio modificato e 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 e sopravvissuto alla manipolazione?

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

Come Redate.io corregge i problemi di date imapsync

L'header Date: originale e sempre intatto dopo una migrazione imapsync. imapsync trasferisce il messaggio grezzo fedelmente; e la gestione dei metadati del server di destinazione che causa il problema di visualizzazione. Quell'header originale e cio 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. La correzione gestisce i pattern specifici che le migrazioni imapsync lasciano dietro, incluse le firme caratteristiche degli header Received dei server di destinazione che hanno sovrascritto l'INTERNALDATE.

Ogni email corretta viene verificata individualmente: integrita del messaggio, preservazione degli allegati, posizionamento nelle cartelle, threading, etichette. Gli originali sono conservati in una cartella di backup visibile Redate.io - Originals per 30 giorni. Se qualcosa non va, l'annullamento e 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 possibilita 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