Da POP a IMAP: le email vecchie datano oggi

Lo scenario classico del lunedì mattina

Ha appena migrato il suo account email da POP3 a IMAP. La configurazione era semplice, il provider l'ha guidata passo dopo passo, tutto sembrava andare bene. Poi ha riaperto la casella. Le email del 2019, del 2021, gli archivi dell'anno scorso... tutte mostrano la stessa data: oggi. A volte persino la stessa ora, a pochi secondi di distanza.

Non è un bug del client mail. Non è un problema di fuso orario. È il comportamento atteso del protocollo IMAP, e colpisce chiunque carichi su un server delle email conservate localmente con questo metodo.

POP3 vs IMAP: una differenza di fondo

Per capire perché accade, bisogna prima capire come funziona POP3, e in che cosa differisce radicalmente da IMAP.

Con POP3, il server funge solo da casella temporanea. Il client (Outlook, Thunderbird, Apple Mail) si connette, scarica i messaggi, poi li cancella dal server (o li lascia, a seconda della configurazione). Le email vivono poi esclusivamente in locale: in un file .pst per Outlook, nel profilo locale di Thunderbird, in un database sul disco fisso.

Con IMAP è l'opposto: le email vivono sul server. Il client si limita a mostrare ciò che è archiviato da remoto. Da qui la sincronizzazione trasparente tra tutti i dispositivi.

Il problema nasce nella transizione tra i due. Quando si caricano le vecchie email POP locali sul server IMAP.

IMAP APPEND: il comando che cambia tutto

Quando il client email carica un messaggio locale su un server IMAP, usa il comando IMAP APPEND. Questo comando dice al server: "archivia questo messaggio in questa cartella".

Il server riceve il messaggio, lo salva e gli assegna un timestamp. Questo timestamp è l'INTERNALDATE. È il metadato centrale di IMAP: indica quando il messaggio è stato depositato sul server. E per default, se il client non specifica esplicitamente una data nel comando APPEND, il server usa... il momento presente.

In altre parole: non importa che il messaggio contenga nelle sue intestazioni una data del 2018, se nessuno dice al server "questa email è del 2018", il server conclude che è stata depositata adesso e gli assegna l'INTERNALDATE di oggi.

(Del resto, se ha mai guardato le intestazioni grezze di un'email, ha visto la riga Date: in mezzo a una decina di altre righe Received:. È quel campo Date:, definito dalla RFC 2822, che contiene la vera data di invio. Ma l'INTERNALDATE IMAP è un metadato separato, archiviato lato server, che non ha nulla a che fare con il contenuto del messaggio.)

Perché è diverso da una migrazione IMAP-to-IMAP

In una migrazione classica da un server IMAP a un altro (con BitTitan, CloudM, imapsync, ecc.), il problema è leggermente diverso. Lo strumento di migrazione copia i messaggi da un server all'altro e, in quel caso, può (in teoria) trasmettere l'INTERNALDATE originale al server di destinazione tramite il comando APPEND. Il problema lì è che alcuni strumenti aggiungono un'intestazione Received: con la data di migrazione, il che disturba la visualizzazione in client come Outlook.

Nel suo caso, parte da dati puramente locali. Non esiste un INTERNALDATE sorgente da copiare. Il file .pst o il profilo Thunderbird archivia i messaggi nel proprio formato proprietario, con i propri metadati interni. Quando il client mail rilegge questi messaggi per caricarli sul server IMAP, ricostruisce il comando APPEND a partire dal contenuto del messaggio. E nella maggior parte dei casi, non trasmette nessuna data esplicita.

Risultato: il server IMAP riceve centinaia o migliaia di messaggi nel giro di pochi minuti, e assegna a tutti la stessa finestra temporale: adesso.

È esattamente per questo che il problema si propaga su tutti i dispositivi immediatamente. Il telefono, il tablet, il secondo computer: si connettono tutti allo stesso server IMAP e vedono esattamente la stessa cosa. Nessuna correzione possibile lato client.

Quale client mostra cosa, e perché

Non tutti i client email reagiscono allo stesso modo. È un punto che molti amministratori IT scoprono solo a posteriori.

Outlook (nelle versioni recenti, soprattutto dopo gli aggiornamenti del 2023-2024) usa l'INTERNALDATE del server per la colonna "Ricevuto". Mostra quindi la data di caricamento, non la data di invio originale. Per approfondire questo comportamento specifico di Outlook, è utile l'articolo Outlook: data ricevuta IMAP vs data di invio.

Gmail / Google Workspace e Thunderbird hanno comportamenti un po' più sfumati. Gmail, ad esempio, può a volte usare il campo Date: dell'intestazione del messaggio per la visualizzazione, il che dà l'impressione che vada tutto bene... finché non si prova a ordinare per data e ci si accorge che l'ordine è completamente casuale.

Apple Mail mostra in genere la data estratta dall'intestazione Date:, ma l'ordinamento e la ricerca passano per l'INTERNALDATE in background. Di conseguenza, le email possono "sembrare" ben datate visivamente, ma la funzione di ordinamento non funziona più correttamente. Per i dettagli sul comportamento di Apple Mail, si veda Apple Mail: data sbagliata dopo migrazione.

La buona notizia: la data originale è intatta

L'intestazione Date: di ogni email, quella che contiene la vera data di invio (o di ricezione), non è stata toccata. È ancora lì, nel corpo del messaggio. È quella che vede quando apre un'email e ne guarda i dettagli.

Ciò che il server IMAP ha "rotto" è solo l'INTERNALDATE, quel metadato esterno al messaggio. Il messaggio in sé è intatto.

È questo che rende possibile la correzione. Ed è anche per questo che il problema può passare inosservato per un po': le email sembrano corrette quando le apre una per una. È solo guardando la lista della casella in entrata, ordinata per data, che il problema diventa visibile. Email del 2019 che appaiono in cima come se fossero appena arrivate. Tutte con la stessa data.

Il problema di scala: 3.000 email sono un'altra cosa

Forse sta pensando: "Basta cancellare e reimportare, questa volta correttamente." Su 5 o 10 email di test, funziona. Su una casella con 8.000 messaggi, cartelle annidate, allegati voluminosi, email firmate con S/MIME e thread che risalgono al 2015... è tutta un'altra storia.

Uno script fatto in casa che funziona su un lotto di test di 50 email può benissimo produrre duplicati, perdere allegati o rompere i thread su una casella di produzione. La gestione delle quote API, dei timeout di rete, dei messaggi con strutture MIME atipiche... altrettanti casi limite che uno strumento non specializzato non gestisce.

E se qualcosa va storto a metà del processo? Senza un meccanismo di backup e rollback, si perdono dati senza possibilità di recupero.

Il problema è ben noto agli admin che gestiscono migrazioni a volume. Capire perché le date si rompono è una cosa. Correggere in modo pulito 15.000 email preservando ogni struttura di messaggio è un'altra. Per approfondire, l'articolo Si possono correggere le date email dopo la migrazione? illustra i diversi approcci e i loro limiti.

Come Redate.io gestisce questo caso specifico

Redate.io è stato progettato esattamente per questo tipo di situazione. Il motore di analisi identifica le email il cui INTERNALDATE non corrisponde alla data contenuta nelle intestazioni del messaggio, che si tratti di una migrazione da POP a IMAP, di una migrazione tra server IMAP, o di un caricamento manuale di archivi locali.

Il pipeline di analisi multi-fase ispeziona la catena di intestazioni di ogni messaggio, valida la conformità RFC e ricostruisce i metadati di data senza alterare il contenuto del messaggio: né il testo, né gli allegati, né la struttura MIME, né le eventuali firme digitali. Ogni email corretta viene verificata individualmente prima della convalida.

Gli originali vengono conservati in una cartella di backup visibile per 30 giorni. Se qualcosa non va, è possibile ripristinare.

La scansione iniziale è gratuita: Redate analizza la casella, identifica le email interessate e indica il numero esatto prima che venga presa qualsiasi decisione. Nessun impegno al buio.

Redate.io si connette direttamente alle caselle tramite Google Workspace (domain delegation), Microsoft 365 (Azure AD), o IMAP diretto. Nessuna installazione locale. Nessun file .pst da esportare e manipolare a mano.

Per gli admin che gestiscono più caselle e vogliono un riscontro pratico su questo tipo di casi, l'articolo MSP: correggere le date email dei clienti è un'ottima lettura complementare. E per le specificità della correzione in Thunderbird, che ha un suo comportamento particolare nel passaggio da POP a IMAP, si veda Thunderbird: data sbagliata dopo la migrazione.

Se deve ancora farlo: come anticipare il problema

Se non ha ancora caricato gli archivi locali sul server IMAP, o se sta pianificando altre migrazioni di account POP nell'organizzazione, ecco cosa tenere a mente.

• Verifichi se il client email supporta il passaggio esplicito della data nel comando APPEND. Thunderbird, ad esempio, ha avuto comportamenti variabili nelle diverse versioni su questo punto.
• Faccia prima un test su un account di validazione con 50-100 messaggi rappresentativi: email vecchie, con allegati, email firmate. Verifichi le date visualizzate in diversi client.
• Pianifichi la correzione prima che gli utenti finali inizino a lavorare sulla casella migrata. Correggere le date su una casella attiva è più complesso che su una casella vuota appena migrata.
• Documenti il numero di email prima e dopo la migrazione. È l'unico modo per rilevare perdite silenziose.

Per una checklist completa dei punti da verificare prima e dopo una migrazione, l'articolo Checklist migrazione email: prevenire i problemi di date copre tutti i casi.

Le email vecchie mostrano la data di oggi dopo il passaggio da POP a IMAP? Avvii una scansione gratuita su Redate.io per misurare l'entità del problema e correggere i metadati di data senza toccare il contenuto dei messaggi.