Migrare email tra provider: cartelle e duplicati

Migrare le email da un provider a un altro sembra semplice finché la prima casella viene copiata due volte e lo storico degli invii sembra scomparire. La posta non è solo un insieme di file: cartelle e identificazione dei messaggi contano.

Si copiano dati IMAP in uso tra due server con regole delle cartelle e comportamento degli UID differenti. Una supposizione errata può lasciare cartelle apparentemente vuote, conversazioni duplicate o corrispondenza divisa tra i sistemi.

Pianificate fasi, mappatura esplicita delle cartelle e verifiche dopo il passaggio. Per scegliere fornitori, valutare prezzi e controllare gli account, consultate la guida alla posta aziendale. Qui ci concentriamo sulla migrazione.

Per passare a TrekMail, iniziate dalla panoramica della migrazione IMAP, poi dalle istruzioni Gmail o cPanel secondo l'origine. Il testo descrive migrazione lato server nei piani a pagamento da $3.50 al mese, Nano gratuito senza carta e prova di 14 giorni dei piani a pagamento. Verificate funzionalità, disponibilità e condizioni attuali.

Che cosa trasferisce una migrazione tra provider?

Uno strumento IMAP accede alla vecchia casella, legge cartelle e messaggi e li copia nella nuova. Non normalizza automaticamente i nomi, non elimina tutti i duplicati esistenti né coordina il DNS senza apposite fasi nel processo.

È una copia tra due sistemi. L'origine può restare intatta, mentre la casella di destinazione riceve messaggi, cartelle e indicatori compatibili, come letto o non letto, se forniti dall'origine. Contatti, calendari e regole non rientrano in questa copia IMAP; verificate ambito e differenze d'identificazione.

La RFC 3501 descrive UID e UIDVALIDITY per cartella IMAP. Identificano i messaggi nella cartella e nella generazione caratterizzata da UIDVALIDITY, non globalmente tra server. Uno strumento che usa questo stato può perdere l'associazione con le copie precedenti se la generazione cambia.

Un primo passaggio apparentemente corretto non garantisce assenza di duplicati al secondo. L'indicazione di completamento nel pannello non sostituisce la verifica dei dati.

Perché compaiono duplicati

Una possibile causa è la perdita della corrispondenza: modifica di UIDVALIDITY, cartelle ricreate o etichette Gmail trattate come cartelle indipendenti. Secondo il metodo di confronto, messaggi già copiati possono essere importati nuovamente.

UIDVALIDITY e stato della sincronizzazione

Alcuni strumenti mantengono una mappatura degli UID per cartella; altri usano intestazioni o criteri diversi. Reindicizzare non modifica necessariamente gli UID. Ricreare una cartella o perdere lo stato può cambiare il confronto. Verificate il meccanismo prima di ripetere l'operazione.

La RFC 3501 collega stabilità degli UID e UIDVALIDITY. Se questa generazione cambia, i vecchi UID non identificano più affidabilmente i messaggi attuali della cartella. Senza un altro confronto attendibile, un secondo passaggio potrebbe ricopiare migliaia di messaggi.

Esempio: il primo passaggio copia 38,000 messaggi dalla posta in arrivo. Dopo un timeout, l'amministratore riavvia il lavoro, ma una cartella è stata ricostruita durante la notte. Senza mappatura affidabile né riconoscimento delle copie esistenti, lo strumento potrebbe aggiungere altri 38,000 messaggi.

Le etichette Gmail

Gmail non funziona esattamente come un server tradizionale a cartelle. Un messaggio può avere diverse etichette; gli archivi compaiono in Tutti i messaggi. Archiviare rimuove dalla posta in arrivo senza rimuovere da questa raccolta.

Importare [Gmail]/All Mail insieme alle cartelle delle etichette può rappresentare lo stesso messaggio più volte a destinazione. Le copie possono essere desiderate per conservare la presentazione in cartelle. Definite come preservare messaggi unici, rappresentare etichette e dimensionare lo spazio.

La guida all'importazione da Gmail aiuta a preparare l'accesso. L'importatore TrekMail usa credenziali IMAP dirette; le password per le app dipendono dalla verifica in due passaggi e dalle regole dell'account. Se non disponibili, valutate un altro metodo autorizzato o uno strumento compatibile con OAuth, senza presumere supporto interattivo nell'importatore.

Questo esempio non è adatto a ogni caso: escludere Tutti i messaggi può omettere archivi senza altre etichette. Prevedete come copiarli, proteggete le credenziali e verificate cifratura e certificati delle connessioni:

imapsync \
  --host1 imap.gmail.com \
  --user1 user@gmail.com \
  --password1 'APP_PASSWORD' \
  --host2 mail.newhost.com \
  --user2 user@example.com \
  --password2 'DEST_PASSWORD' \
  --exclude "\\[Gmail\\]/All Mail" \
  --useheader "Message-ID" \
  --dry

La simulazione non copia messaggi né prova un trasferimento completo. Message-ID può mancare, ripetersi o non essere affidabile: da solo non evita sempre i duplicati. Non esponete password reali nella cronologia della shell o nell'elenco dei processi; effettuate una copia pilota e verificate il contenuto. La guida imapsync approfondisce le opzioni.

Perché alcune cartelle non appaiono

Una cartella può arrivare in un'altra gerarchia, con nome speciale diverso o prefisso visualizzato male. La copia potrebbe anche essere fallita: controllate il server prima di attribuire tutto alla visualizzazione.

Namespace e separatori

I server usano separatori e namespace diversi, come INBOX.Sent, Inbox/Sent Items o un prefisso obbligatorio INBOX..

Senza mappatura verificata, Project.Alpha può diventare sottocartella di Project. Una cartella speciale può apparire come personalizzata; il client mobile potrebbe sottoscrivere quella sbagliata o nascondere quella corretta.

Le cartelle della posta inviata

Un server usa Sent, un altro Sent Items, un altro Sent Messages. Verificate nomi, attributi d'uso speciale della destinazione e configurazione del client.

Se la vecchia cartella arriva come personalizzata senza associazione alla posta inviata, quella predefinita può sembrare vuota anche se lo storico è altrove. Confermate che i messaggi siano stati effettivamente copiati.

Per hosting condiviso, consultate la migrazione da cPanel o altri provider. La guida aiuta a identificare gli accessi comuni, ma provate credenziali, permessi e cartelle dell'origine.

Piano di migrazione in 3 fasi

Un processo in tre fasi può ridurre i rischi: preparate lo storico, sincronizzate le modifiche vicino al passaggio e controllate gli arrivi sul vecchio server dopo la modifica MX. Non garantisce assenza di interruzioni o duplicati. Adattate fasi e ritorno al sistema precedente.

1. Sincronizzazione storica. Copiate prima le vecchie email; oltre 30 giorni è una finestra illustrativa. Gli utenti possono continuare sull'origine, monitorando le modifiche.
2. Sincronizzazione incrementale. Eseguite un secondo passaggio per nuovi messaggi e modifiche pertinenti, inclusi spostamenti e indicatori. Coprite anche arrivi tardivi con data precedente, non solo un filtro dei messaggi recenti, conservando lo stato del confronto.
3. Passaggio e verifiche finali. Modificate MX dopo i test. Mantenete la ricezione sul vecchio server finché cache e nuovi tentativi possono portarvi messaggi, anche oltre il TTL, con le ulteriori sincronizzazioni necessarie.

Errori DNS possono mantenere gli arrivi sul vecchio server o causare rifiuti. Consultate i record DNS necessari durante la preparazione.

; Example cutover records
@      MX   10 mail.trekmail.net.
@      TXT     "v=spf1 include:spf.trekmail.net -all"
_dmarc TXT     "v=DMARC1; p=quarantine;"

Sono esempi, non valori da pubblicare senza controllo: verificate il pannello dell'account, mantenete nel record SPF l'autorizzazione di tutti i servizi di invio legittimi, controllate DKIM allineato e non applicate quarantena senza inventario e test. Dopo aver verificato dati e configurato i client, limitate eventualmente le scritture degli utenti sull'origine per evitare invii divisi. Non interrompete subito la ricezione né l'accesso amministrativo necessario alle sincronizzazioni e al ritorno.

Il metodo aiuta anche le agenzie con diversi marchi. La dispersione operativa supera la copia: consultate l'hosting email multidominio per valutare la centralizzazione.

Verifiche dopo la migrazione

Confrontate conteggi, date dei messaggi più vecchi e più recenti e gerarchie, oltre a campioni di contenuto, allegati e indicatori. Il totale in gigabyte non basta: compressione, indicizzazione e rappresentazione possono variare senza perdita.

1. Confrontare elementi e ambito

Con 4,502 elementi prima del passaggio, aspettatevi 4,502 nella cartella corrispondente quando ambito ed esclusioni approvate coincidono, senza modifiche recenti. L'uguaglianza non dimostra integrità: controllate contenuto, allegati, date e indicatori. Distinguete messaggi Gmail unici e copie per etichetta.

2. Verificare i messaggi più vecchi e più recenti

Confrontate messaggi più vecchi e recenti in arrivo e inviati. Un'assenza richiede di rivedere filtri, mappature e passaggi storici o incrementali; la data da sola non identifica la fase responsabile.

3. Cercare cartelle non associate

Cercate INBOX.Sent nella radice, residui [Gmail] o più cartelle degli invii. Possono segnalare una mappatura errata, ma alcune rappresentazioni sono intenzionali.

4. Provare ricezione e invio reali

Inviate da una casella esterna e rispondete dalla destinazione. Controllate arrivo, autenticazione e cartella della risposta. Estendete le prove ai flussi importanti.

5. Aggiornare i client

Una copia corretta può sembrare incompleta se il client usa il vecchio server. Aggiornate IMAP e SMTP secondo la destinazione e controllate cartelle, sottoscrizioni e accesso degli utenti.

Copia e sostituzione del fornitore vanno quindi pianificate insieme. L'alternativa a Titan Email tratta la stessa transizione: copiare la casella è solo una parte del cambiamento.

Gestione manuale e migrazione con TrekMail

La gestione manuale può moltiplicare attività e mappature particolari. TrekMail descrive migrazione IMAP lato server, spazio condiviso e pannello di domini, caselle e DNS secondo il piano. Verificate protezione dai duplicati e copertura reale; nessun pannello sostituisce i test.

Centralizzare può ridurre il lavoro di team e agenzie. Un luogo invece di cinque è un'illustrazione, non un vantaggio garantito. Consultate i prezzi attuali TrekMail; Nano e prova di 14 giorni dei piani a pagamento dipendono da condizioni e disponibilità vigenti.

Conclusione

Per migrare le email da un provider a un altro, preparate un passaggio IMAP controllato, non una copia massiva senza verifica. Definite cartelle e verificate il trasferimento di tutti i messaggi archiviati Gmail, provate i trasferimenti, sincronizzate le modifiche e verificate dati e client. Rimuovete i vecchi accessi al momento opportuno, mantenendo ricezione e ritorno necessari, senza promettere assenza di perdita o interruzioni.

Per valutare TrekMail come destinazione, visitate trekmail.net. Confrontate hosting multidominio, modello di piattaforma, spazio condiviso e migrazione IMAP con funzionalità e limiti attuali, senza presumere che aggiungere utenti non comporti mai costi ulteriori.