imapsync: guida operativa alla migrazione sicura delle email (2026)

Hai davanti un progetto di migrazione che ti mette in apprensione. Devi spostare la posta dal server A al server B senza perdere neppure un messaggio, senza compromettere la struttura delle cartelle e senza pagare $15 per utente per una "licenza di migrazione" a un fornitore esterno, solo per trasferire dati che già possiedi.

Lo strumento che cerchi è imapsync. Questa guida spiega esattamente come usarlo senza mettere a rischio le caselle dei tuoi utenti.

Che cos'è imapsync (e che cosa non è)

imapsync è un'utilità da riga di comando che sincronizza caselle tra due server IMAP. Funziona da proxy: si collega contemporaneamente ai due server, legge i messaggi dall'origine e li aggiunge alla destinazione. Tiene traccia dello stato, gestisce le interruzioni e conserva struttura delle cartelle, flag e contenuto dei messaggi.

Non è uno strumento di backup. Non è un relay SMTP. Non interviene su Google Calendar, sui contatti di Outlook o sulle regole di trasporto di Exchange. Comunica tramite IMAP e soltanto tramite IMAP. Se il server di origine è protetto da un firewall o non è in linea, imapsync non può raggiungerlo. Punto.

Ciò che lo rende uno standard per gli spostamenti da una casella all'altra è il livello di conservazione dello stato. Una migrazione riuscita non consiste soltanto nello spostare testo, ma nel conservare tre elementi:

• Contenuto: il corpo del messaggio RFC 822, gli allegati, la codifica MIME, ossia tutto ciò che si trova dentro la busta.
• Metadati: i flag. \Seen (letto), \Answered (risposto), \Flagged (contrassegnato). Se non vengono trasferiti, il primo giorno ogni utente penserà di avere 4,000 nuove email non lette.
• Struttura: la gerarchia delle cartelle. INBOX/Clients/ProjectA deve apparire identica sul nuovo server, non ridotta a una cartella chiamata letteralmente INBOX.Clients.ProjectA, con i punti nel nome.

imapsync gestisce tutti e tre gli aspetti, se viene configurato correttamente. È questa la parte difficile ed è a questo che serve la guida.

I limiti principali: non conosce automaticamente i limiti di velocità di Gmail o la limitazione delle API Microsoft. Se lo esegui alla massima velocità, rischi il blocco dell'indirizzo IP. Inoltre non esegue push: se devi inviare i dati altrove, devi prelevarli. Per impostazione predefinita non elimina nulla sulla destinazione. È una protezione utile, ma può anche creare problemi se non presti attenzione, come vedremo nella Fase 6.

Per una panoramica più ampia del protocollo, consulta la nostra guida alla configurazione della posta sul tuo dominio.

Fase 1: analisi preliminare, un passaggio da non saltare

Chi è inesperto inizia subito a copiare. Un professionista verifica prima l'ambiente. Se non sai che cosa stai spostando, la migrazione fallirà, e accadrà alle 2 di domenica mattina, quando sarà troppo tardi per rimediare.

1. Individua le caselle più grandi

Hai un utente con una casella da 45GB. Forse è il CEO, oppure la persona che gestisce l'alias sales@ dal 2011. Se provi a migrarla nello stesso gruppo delle caselle da 500MB, il processo si blocca e ti ritrovi davanti a un terminale immobile senza sapere a che punto sia.

Esegui prima una scansione preliminare:

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfoldersizes

Otterrai le dimensioni di ogni cartella senza modificare alcun messaggio. Le caselle oltre 10GB richiedono una gestione dedicata: timeout più lunghi, una finestra di esecuzione riservata e la tua completa attenzione.

2. Il problema dei dati dimenticati

Ogni azienda ha account fantasma: ex dipendenti la cui posta viene ancora inoltrata, oppure "account di servizio" che in realtà sono caselle condivise per una stampante o un'integrazione CRM obsoleta. Se non li includi nell'inventario, quei dati rimarranno isolati quando cambierai il DNS.

Confronta l'elenco degli utenti sul server di origine con gli utenti realmente attivi. Se bob@company.com ha lasciato l'azienda tre anni fa, decidi subito se migrare la sua casella o archiviarla con un'esportazione EML. Se non decidi prima del passaggio, dovrai farlo sotto pressione nel momento peggiore. La nostra guida alla gestione dell'email dei clienti contiene un modello completo per l'inventario preliminare.

3. Il conteggio reale degli elementi

Non fidarti mai soltanto delle dimensioni in gigabyte. Il server A potrebbe indicare 10GB, mentre il server B potrebbe calcolare 11GB per gli stessi dati. Non è un errore: server diversi calcolano lo spazio in modo diverso. Exchange include la cartella Recoverable Items, detta "Dumpster". Gmail deduplica i messaggi associati a più etichette.

La metrica importante è il numero di elementi. Se l'origine contiene 14,200 messaggi e la destinazione ne contiene 14,200, il lavoro è concluso. Una differenza inferiore al 10% nei byte è normale e prevedibile. Oltre il 10%? Indaga prima di approvare il risultato.

Fase 2: il flusso di migrazione sicuro

L'errore più grave in una migrazione è l'approccio "Big Bang": spostare tutto il venerdì sera e sperare che finisca entro lunedì mattina. Con 50GB di posta e un limite di 500KB/s, i conti non tornano. Lunedì il servizio non sarà disponibile e dovrai spiegare al CEO perché la sua casella è vuota.

L'approccio professionale è una migrazione per fasi. Esegui il trasferimento più pesante mentre gli utenti lavorano ancora sul vecchio sistema, quindi sincronizzi un delta finale minimo al momento del passaggio.

Passaggio 1: la simulazione

Prima di spostare un solo byte, verifica che la connessione funzioni. Usa --dry insieme a --justfolders. In questo modo simuli l'esecuzione e visualizzi la struttura delle cartelle senza copiare nulla.

imapsync \
  --host1 imap.gmail.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.trekmail.net --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfolders

Controlla due aspetti: se l'autenticazione è riuscita e come appaiono i nomi delle cartelle. Se all'origine trovi [Gmail]/Sent Mail, dovrai mapparla su Sent Items nella destinazione. Non aspettare il passaggio effettivo per scoprirlo.

Passaggio 2: la sincronizzazione principale (pre-caricamento)

Eseguila 1-2 settimane prima del passaggio, mentre gli utenti lavorano ancora sul vecchio sistema. L'obiettivo è togliere dal percorso critico il 90-95% dei dati.

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --usecache --skipsize --maxsize 25000000

--usecache è indispensabile. Salva localmente lo stato della migrazione. Ogni esecuzione successiva confronta i dati con la cache ed elabora soltanto le modifiche, senza riesaminare da zero ogni messaggio. Senza questa opzione, ogni esecuzione comporta una scansione completa.

--maxsize 25000000 esclude al primo passaggio i messaggi oltre 25MB. Gli allegati di grandi dimensioni causano la maggior parte dei timeout e delle interruzioni di connessione. Potrai recuperarli con un'esecuzione dedicata e timeout più lunghi.

Passaggio 3: la sincronizzazione delta

Qualche giorno prima del passaggio, esegui di nuovo imapsync. Il programma legge la cache, rileva che 10,000 email sono già presenti nella destinazione, le salta e copia soltanto i 50-100 nuovi messaggi arrivati dopo la sincronizzazione principale. Questa esecuzione dovrebbe durare pochi minuti, non ore.

Passaggio 4: il cambio di sistema

È il momento decisivo. Procedi in questo ordine:

1. Riduci il TTL DNS: 48 ore prima del cambio, imposta il TTL del record MX su 300 secondi. Se aspetti l'ultimo momento, alcuni resolver conserveranno nella cache il vecchio record MX fino a 24 ore e la posta continuerà ad arrivare sul vecchio server dopo il passaggio.
2. Modifica i record MX: indirizzali al nuovo provider.
3. Attendi 60 minuti perché la propagazione si stabilizzi sui principali resolver.
4. Esegui il delta finale: un ultimo passaggio di imapsync recupera i messaggi arrivati sul vecchio server durante la propagazione.

Per una spiegazione dettagliata della finestra DNS e dei controlli da eseguire durante la propagazione, consulta la guida alla configurazione della posta sul tuo dominio.

Fase 3: flag, cartelle e la trappola della posta inviata

I server IMAP parlano dialetti diversi. Se non li traduci, gli utenti troveranno una casella dalla struttura compromessa e daranno giustamente la colpa a te.

Il problema del delimitatore

È il problema tecnico più comune, di cui nessuno parla finché non lo incontra.

I server IMAP usano caratteri diversi per separare i livelli della gerarchia delle cartelle:

• Dovecot usa in genere un punto: INBOX.Clients.ProjectA
• Exchange/Outlook usa una barra: INBOX/Clients/ProjectA
• Alcuni server non usano alcun separatore e si affidano al comando IMAP NAMESPACE

Con una migrazione alla cieca, imapsync potrebbe creare sulla destinazione una cartella chiamata letteralmente INBOX.Clients.ProjectA: un'unica cartella piatta con punti nel nome, non una gerarchia annidata su tre livelli. La struttura di ogni utente sembrerà esplosa.

La soluzione è --regextrans2, che riscrive al volo i percorsi delle cartelle tramite espressioni regolari. Prima di eseguire un gruppo di 100 utenti, verifica sempre la creazione delle cartelle con --dry su un solo account di prova.

Il caos della posta inviata

Ogni server assegna un nome diverso alla cartella della posta inviata. Non è un fastidio trascurabile: ignorarlo rovina l'esperienza degli utenti.

Senza una mappatura, l'utente si ritrova con due cartelle della posta inviata: quella attiva, Sent Items, e una nuova cartella fantasma chiamata Sent Mail che contiene tutta la cronologia. Se ne accorgerà e non ne sarà contento.

Mappale esplicitamente:

--regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/'

Questa opzione indica a imapsync: "Se la cartella di origine inizia con [Gmail]/Sent Mail, rinominala Sent Items nella destinazione". Prima di procedere, esegui l'intera mappatura delle cartelle con --dry per verificare che ogni regola venga applicata correttamente.

La trappola Tutti i messaggi di Gmail

Gmail ha una cartella chiamata [Gmail]/All Mail. Contiene una copia di ogni singola email, indipendentemente dall'etichetta. È la vista interna generale di Gmail, esposta come cartella IMAP.

Se migri All Mail insieme a Inbox e Sent Mail, ogni email verrà duplicata due o tre volte nella destinazione. Una casella da 10GB diventerà da 30GB. Ogni messaggio apparirà più volte. È un disastro.

Escludila sempre:

--exclude "All Mail"

Escludi anche [Gmail]/Spam e [Gmail]/Trash, salvo che tu abbia un motivo preciso per trasferirle. Nessuno desidera migrare il vecchio spam.

Fase 4: ottimizzazione delle prestazioni e limitazione della velocità

Non puoi riversare dati senza limiti verso Google o Microsoft. La loro infrastruttura tratta una connessione IMAP ad alto volume come un attacco denial-of-service, perché dal suo punto di vista l'aspetto è lo stesso.

Le conseguenze del superamento dei limiti

Supera i limiti di velocità, in genere circa 1 messaggio al secondo o 500MB all'ora per Gmail, e il server inizierà a restituire errori HTTP 429, NO [OVERQUOTA] o semplicemente BAD. Se continui, l'account potrebbe rimanere bloccato fino a 24 ore. È una chiamata all'assistenza che conviene evitare.

Le opzioni di regolazione

--maxmessagespersecond 1     # Hard speed limit: 1 email per second
--maxbytespersecond 500000   # Bandwidth cap: 500KB/s
--timeout 120                # Network timeout in seconds (default is often too short for big attachments)
--reconnectretry1 3          # Retry on source connection drops
--reconnectretry2 3          # Retry on destination connection drops

1 messaggio al secondo sembra terribilmente lento, e lo è. Tuttavia è costante, e un processo costante arriva alla fine. Un'esecuzione aggressiva bloccata all'ora 3 non finirà mai.

Nota per gli MSP: se esegui migrazioni parallele per più clienti, non lanciarle contemporaneamente contro lo stesso server di origine. Sfalsa gli orari di avvio. Ogni flusso parallelo deve avere un proprio limite di velocità.

Se stai migrando verso TrekMail, l'acquisizione IMAP è progettata per gestire molte connessioni simultanee. Sul lato destinazione puoi quindi procedere, in genere, più rapidamente rispetto al lato origine con Google o Microsoft.

Fase 5: autenticazione, l'ostacolo dell'autenticazione moderna

I tempi in cui bastava inserire password123 in un file di testo non cifrato sono finiti. Sia Google sia Microsoft hanno dismesso l'autenticazione di base per IMAP. Se provi le normali credenziali di accesso, riceverai un errore di autenticazione e perderai un'ora a chiederti dove hai sbagliato.

Password per le app (per le PMI)

Per la maggior parte delle migrazioni di un singolo dominio, le password per le app sono la strada più rapida. Sono stringhe di 16 caratteri che aggirano la 2FA e funzionano con i client IMAP meno recenti:

1. Accedi all'account di origine (Gmail, Workspace e così via)
2. Attiva l'autenticazione a 2 fattori, se non è già attiva (è necessaria per generare password per le app)
3. Vai a Impostazioni di sicurezza → Password per le app
4. Genera una password per "Mail" su "Altro dispositivo"
5. Usa la stringa come password nel parametro --passfile di imapsync

Conservala in un file con chmod 600, non nella riga di comando. Lasciare le credenziali nella cronologia di bash è un problema pronto a manifestarsi.

OAuth2 (per MSP e aziende)

Se sei un MSP e devi migrare 500 utenti, non puoi generare manualmente 500 password per le app. Ti serve OAuth2. È una procedura più complessa, ma l'unica opzione realistica su larga scala:

1. Registra un'applicazione nel tenant di origine (Azure AD per Microsoft, Google Cloud Console per Google)
2. Concedile l'accesso completo alle caselle del tenant (è necessaria l'approvazione di un amministratore globale)
3. Genera un token di aggiornamento per utente oppure usa l'impersonificazione di un account di servizio
4. Passa il token a imapsync tramite --oauthaccesstoken1

Se configuri in modo errato le autorizzazioni dell'applicazione in Azure AD o GCP, riceverai un accesso negato per ogni casella oppure, peggio, concederai per errore autorizzazioni più ampie del necessario. Leggi con attenzione gli ambiti di autorizzazione prima di fare clic su "Grant admin consent".

Per un esempio pratico di migrazione su larga scala, consulta il nostro approccio alla gestione dell'email dei clienti.

Fase 6: problemi comuni e ripristino

Anche un piano perfetto incontra ostacoli. Ecco come capire che cosa è andato storto e risolverlo senza ricominciare da capo.

1. Il problema UIDVALIDITY (lo scenario peggiore)

Ogni cartella IMAP ha un identificatore univoco chiamato UIDVALIDITY. imapsync lo usa per sapere quali messaggi sono già stati copiati. Se una cartella sul server di origine viene eliminata e ricreata, oppure se l'indice del server si danneggia e viene ricostruito, questo ID cambia.

Sintomo: imapsync rileva un nuovo UIDVALIDITY, presume che si tratti di una cartella del tutto nuova e scarica di nuovo ogni messaggio. Ora ogni messaggio della cartella è duplicato. Su larga scala, significa migliaia di duplicati distribuiti su centinaia di caselle.

Soluzione: elimina i file della cache locale nella directory temporanea, quindi esegui di nuovo il comando con --useheader:

--useheader

Questa opzione obbliga imapsync a confrontare l'intestazione Message-ID di ogni email, che è immutabile e univoca, invece di affidarsi all'UID della cartella. È più lenta, ma impedisce i duplicati. Usala ogni volta che sospetti una modifica all'indice del server di origine.

2. Messaggi danneggiati o di zero byte

I server meno recenti accumulano messaggi "fantasma": intestazioni senza corpo o file di 0 byte esatti. In genere sono il risultato di un'importazione malriuscita, di una consegna interrotta o di anni di manutenzione rimandata su un server molto vecchio.

Sintomo: imapsync prova a recuperare un messaggio, il server resta in attesa per 120 secondi e poi interrompe la connessione. La sequenza si ripete senza fine sullo stesso messaggio.

Soluzione:

--minbytes 10

Questa opzione indica a imapsync di saltare i messaggi più piccoli di 10 byte. Una vera email non è mai più piccola di 10 byte. Di fatto è un filtro che ignora i file vuoti e può essere usato in sicurezza in ogni migrazione.

3. Il problema delle eliminazioni fantasma

Hai eseguito la sincronizzazione principale lunedì. Martedì l'utente ha eliminato 50 email dall'origine. Mercoledì esegui il delta.

Per impostazione predefinita, imapsync aggiunge soltanto la posta e non elimina nella destinazione ciò che è stato eliminato dall'origine. È una scelta intenzionale e corretta per la maggior parte dei casi, ma significa che le 50 email eliminate ricompariranno nella nuova casella. Gli utenti le segnaleranno come "email fantasma" o "email eliminate che sono tornate".

La soluzione è --delete2, da usare però con estrema cautela:

--delete2

Questa opzione indica a imapsync di eliminare dalla destinazione ogni messaggio che non è presente nell'origine.

Usala soltanto durante il pre-caricamento, prima di modificare i record MX. Se la esegui dopo il passaggio, la nuova posta arrivata nella destinazione, perché i record MX puntano già lì, verrà eliminata in quanto assente dalla vecchia origine. Perderai dei messaggi. Non usare --delete2 dopo il passaggio.

4. Interruzioni di connessione con allegati grandi

Un PDF allegato da 40MB può bloccare le connessioni IMAP con un timeout breve. Il server invia il messaggio, la rete ha un'interruzione, la connessione cade al 95% e imapsync registra un errore e passa oltre, lasciando un messaggio incompleto nella destinazione.

Soluzione: aumenta --timeout a 300 secondi per i passaggi dedicati agli allegati grandi e valuta --maxsize 25000000 per escluderli dalla sincronizzazione principale. Esegui poi un passaggio specifico con limiti meno rigidi e timeout più lunghi.

Verifica: come dimostrare che ha funzionato

Lo script è terminato e il terminale indica che ha finito. Come fai a sapere che le email del CEO non sono scomparse nel nulla per un errore di instradamento?

1. Leggi il riepilogo

imapsync stampa un riepilogo alla fine di ogni esecuzione. I tre numeri importanti sono:

• Transferred: dovrebbe essere 0 nel delta finale. Se è diverso da zero, ci sono ancora messaggi che non sono arrivati.
• Skipped: dovrebbe corrispondere al numero totale di messaggi nell'origine, o superarlo. Sono i messaggi già presenti nella destinazione.
• Errors: dovrebbe essere 0. Qualsiasi valore diverso da zero richiede un'indagine prima di dichiarare conclusa la migrazione.

2. Il controllo a campione

Accedi alla nuova casella con un client IMAP appena configurato, non con uno che usa una cache locale, perché vanificherebbe il controllo. Verifica:

• Posta inviata: sono presenti anni di messaggi inviati, nelle cartelle corrette?
• Una sottocartella annidata in profondità: la gerarchia è corretta?
• L'email più recente: è la stessa che appare nell'origine?
• Un messaggio contrassegnato: l'attributo \Flagged è stato trasferito?

3. La ricerca forense

Un utente segnala un'email mancante. Prima di dire "deve essere andata persa", controlla il registro:

grep -i "bob@sender.com" /var/log/imapsync/user@source.com.log

Il registro riporta l'esito di ogni singolo messaggio: Transferred, Skipped (già presente nella destinazione) oppure Error con il codice specifico. In caso di errore, saprai esattamente quale messaggio, cartella e codice lo hanno causato. È questo il punto di partenza per il ripristino, non le supposizioni.

4. La verifica del numero di elementi

Come controllo finale, interroga direttamente entrambi i server:

# On source (example for Dovecot)
doveadm mailbox status -u user@source.com messages '*'

# Or use imapsync's own count
imapsync ... --dry --justfoldersizes 2>&1 | grep "Messages"

Confronta il numero di elementi nell'origine e nella destinazione. Dovrebbero differire al massimo dell'1-2%, considerando le cartelle spam escluse e la deduplicazione di Gmail All Mail. Se la differenza è maggiore, analizza il registro degli errori prima di approvare il risultato.

L'alternativa: evitare il terminale

Abbiamo scritto questa guida perché crediamo nella trasparenza. imapsync è lo strumento adatto agli operatori che desiderano il controllo completo e non temono di lavorare con dipendenze Perl, registrazioni di app OAuth2 e analisi forense dei registri.

Per molti operatori, tuttavia, sia per chi sposta il primo dominio sia per un'agenzia che migra 200 postazioni di clienti, il tempo richiesto per configurare tutto supera il risparmio sul software.

Lo strumento di migrazione integrato di TrekMail opera sul server: niente cartelle trascinate in Outlook per tre ore e niente complicazioni con le dipendenze Perl. Indichi l'origine, come Gmail, cPanel o qualsiasi server IMAP standard, inserisci le credenziali e il server gestisce il trasferimento. Puoi seguirne l'avanzamento dalla dashboard.

Anche il modello tariffario è diverso da quello a cui probabilmente sei abituato. Nessuna tariffa per utente. I piani a prezzo fisso partono da $3.50 al mese e sono pensati per un massimo di 100 utenti su 50 domini, con spazio condiviso tra tutti. Il dirigente con 40GB di allegati non ti costringe a cambiare piano per tutti: lo spazio è condiviso nell'intero account.

Per confrontare ciò che comprende ogni piano, consulta i prezzi di TrekMail. Per una procedura dettagliata dedicata allo strumento, consulta la guida Avviare una migrazione nella documentazione.

Che tu scelga uno script imapsync o la nostra piattaforma, l'obiettivo è lo stesso: spostare l'email senza perdere dati, senza problemi e senza pagare un pedaggio per postazione.

Se vuoi smettere di pagare tariffe per utente e preferisci che la migrazione venga gestita per te, prova TrekMail gratuitamente: 14 giorni di prova, senza carta.