Migrazione email: 7 errori pericolosi

La migrazione email sembra una copia finché i messaggi non iniziano ad arrivare in due posti, gli utenti non rispondono a vecchie conversazioni ricevendo errori e qualcuno scopre che la casella del dirigente è 85GB più grande di quanto preveda il piano acquistato. Se ti interessano gli strumenti, comincia da questa guida operativa a imapsync. Questo articolo è il runbook per i problemi circostanti: DNS, associazione delle cartelle, limitazioni, quote e casi estremi che trasformano una migrazione ordinaria in un disservizio per tutto il fine settimana.

Il problema è semplice: le persone trattano la posta come file. L'aggravante è peggiore: le caselle continuano a cambiare durante il trasferimento, le cache DNS mostrano dati vecchi e i server IMAP non concordano sul comportamento delle cartelle. La soluzione non richiede eroismo, ma preparazione, verifica e rifiuto delle scorciatoie che sembrano innocue alle 6 PM e catastrofiche alle 9 AM di lunedì.

Perché la migrazione email fallisce in produzione

La migrazione fallisce quando viene trattata come un solo evento invece che come una sequenza controllata: inventario, precaricamento, passaggio, sincronizzazione delta e convalida. La posta è un dato vivo. Il DNS viene memorizzato. I client si comportano in modo incoerente. Saltando uno strato non ottieni un trasferimento pulito, ma consegna parziale, duplicati o perdita silenziosa di dati.

1. L'incoerenza DNS causa il primo disservizio

Il primo errore di solito non è la copia, ma l'instradamento. Alcuni mittenti adottano il nuovo MX in pochi minuti. Altri mantengono quello vecchio nella cache per ore. In questa finestra, la posta può arrivare a entrambi i sistemi. Se il vecchio host è già spento, i messaggi tornano indietro. Se è attivo, vi restano bloccati.

Microsoft consiglia di accorciare il TTL del record MX prima del passaggio IMAP, in modo che gli aggiornamenti si propaghino rapidamente. È un consiglio noioso, ma salva le migrazioni. Se il TTL attuale è 86,400 secondi e cambi MX la notte del trasferimento, hai già perso il controllo dei tempi.

;; T-48 hours: inspect current MX TTL
example.com.  86400  IN MX 10 oldmail.example.com.

;; T-48 hours: lower it before cutover
example.com.    300  IN MX 10 oldmail.example.com.

;; T-0: switch to new provider
example.com.    300  IN MX 10 mail.trekmail.net.

Se passi a TrekMail, ricava i record esatti da Aggiungere un dominio a TrekMail e verifica che il dominio diventi attivo prima di annunciare il trasferimento. TrekMail controlla il DNS in tempo reale e aiuta a trovare il classico errore di lasciare vecchi record MX.

Passaggio sbagliato: cambiare MX alle 10 PM, dismettere il vecchio host alle 10:05 PM e scoprire lunedì che il gateway di un fornitore ha conservato il vecchio record per tutto il weekend.

Un'altra trappola è SPF. Se la posta in entrata punta al nuovo sistema, ma l'autenticazione in uscita è ancora errata, le risposte finiscono nello spam. Le regole di Google per i mittenti non sono più facoltative. Usa un solo record SPF, allinea DKIM e pubblica DMARC.

2. Le limitazioni distruggono la fantasia di migrare in un weekend

Il secondo errore è la fisica. Il collo di bottiglia di solito non è la banda locale, ma il provider sorgente che decide che per ora hai copiato abbastanza. Google, Microsoft e altri sistemi ospitati limitano il traffico IMAP aggressivo. Le previsioni diventano finzione e il lavoro rallenta drasticamente o si ferma.

Ecco perché una migrazione in una sola volta è un pessimo piano per chiunque non sia un team minuscolo. Una casella da 10GB in un ambiente che permette solo una frazione al giorno non finirà perché lo desideri. I limiti di frequenza ignorano la finestra di manutenzione.

La soluzione è una migrazione a fasi:

1. Precaricare prima la posta vecchia, in genere tutto ciò che ha più di 60 fino a 90 giorni.
2. Lasciare che lo strumento riprovi e attenda durante la settimana.
3. Cambiare MX solo quando il volume storico è già a destinazione.
4. Eseguire un delta della posta recente durante il passaggio.

L'importazione IMAP lato server di TrekMail è pensata per questo flusso. La guida Avviare una migrazione dal pannello conferma che lo strumento preleva la posta da un server IMAP esterno verso una casella TrekMail scelta e supporta l'opzione Ignora duplicati. Ripetere i passaggi è normale in una migrazione sicura, non un segno di errore.

Vecchio metodo e nuovo metodo: i vecchi provider fanno pagare per utente e poi vendono separatamente gli strumenti di migrazione. Nel nuovo metodo prepari il trasferimento con migrazione IMAP integrata, paghi un piano fisso a partire da $3.50 al mese e smetti di trasformare ogni casella in una nuova licenza.

3. UIDVALIDITY può creare tre copie della stessa casella

Questo errore si nasconde dietro una barra di avanzamento apparentemente positiva. I messaggi IMAP hanno identificatori univoci, affidabili però solo secondo le regole della propria casella. Quando il server modifica lo stato della cartella abbastanza da reimpostare UIDVALIDITY, uno strumento ingenuo può scambiare messaggi vecchi per nuovi e copiarli di nuovo.

IMAP4rev1 (RFC 3501) definisce UIDVALIDITY per un motivo. Se cambia, i vecchi UID non sono più affidabili. È il normale comportamento del protocollo, ma è terribile per uno strumento che si affida soltanto agli UID.

Cause tipiche:

• Un utente rinomina o ricrea una cartella durante il trasferimento.
• Il server sorgente ricostruisce gli indici.
• Un amministratore esegue manutenzione che cambia lo stato della casella.

La difesa pratica è semplice. Blocca la manutenzione delle caselle durante la migrazione. Chiedi agli utenti di non rinominare cartelle, spostare migliaia di messaggi nell'archivio o pulire gli elementi inviati mentre la sincronizzazione è attiva. Usa una destinazione capace di ignorare duplicati nei passaggi ripetuti invece di fidarsi ciecamente degli UID.

Nella convalida manuale, confronta i conteggi delle cartelle prima e dopo. Non fermarti alla posta in arrivo. Controlla inviati, cestino, cartelle personalizzate dei progetti e archivi condivisi. È lì che si nascondono le valanghe di duplicati.

4. L'associazione delle cartelle rende subito strana la migrazione

L'associazione interrompe le migrazioni perché i server IMAP non concordano su separatori gerarchici, nomi delle cartelle di sistema e modello delle etichette Gmail. Gli utenti vedono cartelle mancanti o messaggi duplicati. Tecnicamente la posta spesso è presente, ma organizzata male, abbastanza da generare panico e ticket.

Esistono due versioni comuni. Primo, separatori diversi: un server usa punti nei nomi, un altro barre. Secondo, le etichette Gmail: un messaggio può apparire sotto più etichette che IMAP presenta come cartelle.

Così una casella Gmail ordinata diventa una destinazione gonfia, con messaggi ripetuti negli inviati, nelle cartelle personalizzate e negli archivi. La documentazione Microsoft segnala espressamente i duplicati con le etichette Gmail quando la cartella [Gmail] non viene esclusa.

# Example folder rules
^INBOX\.Sent$        -> Sent Items
^INBOX\.Trash$       -> Deleted Items
^\[Gmail\]/Trash$   -> Deleted Items
^\[Gmail\]/All Mail$ -> [SKIP]

Se migri da Gmail, ignora [Gmail]/All Mail salvo un'eccezione molto precisa. Altrimenti stai chiedendo duplicati. Dopo il trasferimento, TrekMail semplifica la configurazione dei client con valori standard nella guida Impostazioni IMAP e SMTP per tutti i client.

5. La casella enorme distrugge budget e tempi

I piani di migrazione spesso falliscono sulle medie. Gli ambienti reali falliscono sulle eccezioni. Una casella che raccoglie posta dal 2011 può essere più grande di dieci utenti normali insieme. Se prepari il preventivo, scegli il piano di destinazione e fissi i tempi senza misurare ogni casella, una sola eccezione distruggerà il progetto.

È la trappola della riduzione delle licenze. I sistemi sorgente, soprattutto le vecchie installazioni locali, spesso tolleravano caselle enormi. Molte piattaforme ospitate no. Quando la quota di destinazione è inferiore alla dimensione reale, la migrazione non fallisce subito e con garbo. Spesso fallisce tardi, dopo ore di trasferimento sprecate.

Esegui prima un inventario. Nessuna eccezione. Poi decidi se il modello di destinazione supporta dimensioni diseguali senza costosi upgrade individuali.

Qui lo spazio condiviso è operativamente migliore di quello per utente. Con TrekMail, lo spazio viene condiviso nell'account anziché costringere ogni casella nello stesso contenitore ridotto. Conta per fondatori, caselle legali e posta in arrivo condivisa delle agenzie. Per chi gestisce molti domini, l'hosting email per più domini funziona soltanto se il modello non penalizza le eccezioni.

Per controllare il consumo dopo il trasferimento, TrekMail descrive limiti e quote in Quote di spazio delle caselle.

6. I messaggi corrotti sono normali e richiedono regole operative

Una migrazione pulita non significa che ogni elemento sia valido. I vecchi archivi accumulano strutture MIME danneggiate, allegati vuoti e inviti di calendario malformati. Se il processo si ferma su ogni elemento errato, un messaggio guasto del 2014 può bloccare una migrazione altrimenti corretta.

Qui si confonde la precisione con la competenza. Serve una traccia di controllo, non l'intero lotto congelato perché un allegato inutilizzabile non può essere analizzato.

Definisci una soglia per gli elementi errati. Registra ogni elemento saltato, esamina il rapporto e prosegui. La maggior parte è spazzatura, duplicati di sistemi precedenti o vecchi inviti malformati che nessuno usa. Se il CSV degli elementi saltati contiene qualcosa di importante, recupera manualmente il messaggio. È comunque più rapido che tenere in ostaggio l'intera migrazione.

Il flusso integrato di TrekMail mostra avanzamento ed errori nel pannello. Se dopo il passaggio la posta non arriva dove previsto, la verifica più rapida è Non ricevo messaggi, che guida nel controllo di MX e caselle.

7. LegacyExchangeDN è la trappola esclusiva di Exchange che sopravvive

Questo errore è specifico, sgradevole e comune. Gli utenti rispondono in Outlook a una vecchia conversazione interna e ricevono un errore IMCEAEX o destinatario inesistente, anche se la casella esiste e i nuovi messaggi funzionano. Il motivo non è SMTP, ma la vecchia identità Exchange incorporata nelle comunicazioni storiche e negli indirizzi memorizzati.

Exchange conserva l'indirizzamento storico in stile X.500 nell'attributo LegacyExchangeDN. Migrando fra ambienti Exchange, o uscendo male da uno di essi, le risposte ai vecchi messaggi possono ancora usare quell'identità. Se la destinazione non include il vecchio valore come indirizzo proxy X500, la risposta fallisce.

# Find the old LegacyExchangeDN on source
Get-Mailbox -Identity user@example.com | Format-List LegacyExchangeDN

# Add it as an X500 proxy address on destination
Set-Mailbox -Identity user@example.com -EmailAddresses @{add="X500:/o=OldOrg/ou=Exchange Administrative Group/cn=Recipients/cn=user"}

Non riguarda tutte le migrazioni, perché i semplici trasferimenti IMAP non portano oggetti nativi di Exchange come quelli completi. Ma se gli utenti Outlook devono continuare a rispondere alle vecchie conversazioni interne senza errori, verifica prima dell'approvazione. È uno di quei problemi che compaiono solo dopo la chiusura del progetto.

Un piano di passaggio più sicuro

Una migrazione sicura è volutamente graduale, misurata e noiosa. Questo è l'obiettivo. Servono meno sorprese, non più automazione fine a se stessa. I passaggi migliori sembrano privi di eventi perché il lavoro rischioso è avvenuto prima del cambio MX.

1. Censire la dimensione di ogni casella e segnalare quelle insolitamente grandi.
2. Abbassare il TTL del record MX da 24 a 48 ore prima del passaggio.
3. Creare prima i domini e le caselle di destinazione.
4. Eseguire la sincronizzazione IMAP storica prima del fine settimana.
5. Bloccare pulizia delle cartelle e spostamenti in massa durante il delta finale.
6. Cambiare MX solo quando la destinazione è pronta a ricevere.
7. Eseguire un'ultima sincronizzazione delta.
8. Provare entrata, uscita, conteggi delle cartelle e risposte alle vecchie conversazioni.

Se costruisci la destinazione da zero, creare email con il proprio dominio descrive la sequenza, mentre creare account email in massa aiuta quando devi configurare più di pochi utenti.

Per TrekMail, il percorso è diretto: aggiungere il dominio, verificare il DNS, creare le caselle, eseguire la migrazione IMAP integrata con un piano a pagamento e cambiare il traffico attivo al termine della copia pesante. I prezzi partono da $3.50 al mese. I piani a pagamento includono una prova gratuita di 14 giorni con carta obbligatoria. Nano è separato: senza carta, senza prova e sempre gratuito.

Conclusione: la migrazione email è un lavoro operativo, non una copia

La migrazione riesce quando si rispettano gli aspetti difficili: DNS in cache, sorgenti limitate, comportamento IMAP incoerente, quote diverse e residui di Exchange. Ignorandoli, il progetto sembra corretto finché gli utenti non iniziano a perdere messaggi. Tratta la migrazione come infrastruttura attiva e diventerà prevedibile. Questo è il punto.

Se dopo il trasferimento vuoi un modello a prezzo fisso, TrekMail offre più domini, spazio condiviso, migrazione IMAP integrata, inoltro, accesso API e configurazione basata su standard senza tariffe per utente. Inizia da trekmail.net o confronta i piani su Prezzi TrekMail.