Le tre date all'interno di ogni email
Ogni email memorizzata su un server IMAP porta almeno tre valori di data distinti. Capire come queste date funzionano, e come i client di posta scelgono quale visualizzare, e la chiave per comprendere perche la migrazione altera le date. Questo articolo e un'analisi tecnica approfondita del sistema di date IMAP, destinata agli amministratori informatici e a chiunque desideri comprendere la causa profonda dei problemi di date post-migrazione.
1. L'header "Date" RFC 2822
L'header "Date" e definito nella RFC 2822 (formato dei messaggi Internet). Viene impostato dal client di posta del mittente al momento in cui il messaggio viene composto e inviato. Questo header fa parte del corpo del messaggio stesso - viaggia con il messaggio e non viene mai modificato dai server di posta lungo il percorso di consegna. Un tipico header Date si presenta cosi:
Date: Mon, 15 Jan 2024 09:32:17 +0100
L'header Date rappresenta la "data di invio" del messaggio. E la data piu affidabile perche viene impostata una sola volta e mai alterata. Tuttavia, riflette l'orologio del mittente, che potrebbe essere configurato male. In rari casi, l'header Date puo essere del tutto assente (in particolare nelle notifiche di sistema automatizzate o nei messaggi malformati).
2. L'IMAP INTERNALDATE
L'INTERNALDATE e definito nella RFC 3501 (protocollo IMAP4rev1). E un valore di metadato lato server che rappresenta la data e l'ora in cui il messaggio e stato consegnato al server. A differenza dell'header Date, l'INTERNALDATE non fa parte del messaggio email stesso. Viene memorizzato separatamente dal server IMAP come metadato.
Quando un'email viene consegnata normalmente (non migrata), il server IMAP imposta l'INTERNALDATE all'ora corrente al momento della consegna. Questo valore corrisponde da vicino all'header Date, generalmente con uno scarto di pochi secondi o minuti. I client di posta utilizzano spesso l'INTERNALDATE come "data di ricezione" perche riflette il momento in cui il server ha effettivamente ricevuto il messaggio.
Ed e qui che diventa interessante. Quando un messaggio viene inserito tramite il comando IMAP APPEND (cio che utilizzano gli strumenti di migrazione), il comando APPEND consente al client di specificare l'INTERNALDATE esplicitamente. Gli strumenti di migrazione ben progettati utilizzano questa funzionalita per preservare l'INTERNALDATE originale dal server sorgente. Ma anche quando l'INTERNALDATE e correttamente impostato, il problema dell'header "Received" (descritto di seguito) puo comunque sovrascrivere la data visualizzata in molti client.
3. La catena degli header "Received"
Ogni volta che un'email passa attraverso un server di posta, quel server aggiunge un header "Received" all'inizio del messaggio. Questo crea una catena di header Received che registra il percorso dell'email dal mittente al destinatario. Il piu recente (in cima) mostra l'ultimo server che ha elaborato il messaggio, e il piu vecchio (in basso) mostra il primo.
Un'email normale puo avere 3-6 header Received, documentando il viaggio dal server in uscita del mittente attraverso i relay fino al server in entrata del destinatario. Ogni header Received include un timestamp. Ecco un esempio semplificato:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Come i client di posta scelgono quale data visualizzare
Outlook (Desktop, Web, Mobile)
Microsoft Outlook utilizza una combinazione dell'INTERNALDATE e dell'header "Received" piu recente per determinare la data di "Ricezione" visualizzata nella posta in arrivo. In pratica, Outlook tende a privilegiare il timestamp dell'header Received piu recente per la colonna "Ricevuto". La colonna "Inviato" utilizza l'header Date. Dato che Outlook ordina per impostazione predefinita per la colonna "Ricevuto", e il timestamp dell'header Received che gli utenti vedono per primo.
Apple Mail
Apple Mail su macOS e iOS utilizza principalmente l'IMAP INTERNALDATE per visualizzare la data. Se l'INTERNALDATE e stato correttamente preservato durante la migrazione, Apple Mail puo mostrare la data corretta - ma solo se l'INTERNALDATE e stato esplicitamente impostato durante l'operazione APPEND. Se lo strumento di migrazione non ha impostato l'INTERNALDATE, il server utilizza per impostazione predefinita l'ora di inserimento (la data di migrazione). Per i dettagli sull'impatto per gli utenti Apple Mail, vedere Apple Mail: data sbagliata dopo la migrazione.
Thunderbird
Mozilla Thunderbird offre la massima flessibilita. Puo visualizzare sia "Data" (dall'header Date) che "Ricevuto" (dagli header Received). Per impostazione predefinita, Thunderbird mostra il valore dell'header Date, il che significa che le date possono apparire corrette in Thunderbird anche quando sono sbagliate in Outlook. La colonna "Ricevuto" in Thunderbird mostra sempre la data di migrazione. Vedere Thunderbird: data sbagliata dopo la migrazione per maggiori dettagli.
Interfaccia web Gmail
Il client web di Gmail utilizza l'header Date per la propria visualizzazione principale della data. Questo significa che Gmail web mostra spesso date corrette anche dopo la migrazione. Ma l'IMAP INTERNALDATE sul server Gmail e comunque errato, il che colpisce ogni client IMAP che si collega a quell'account Gmail. La differenza tra Gmail web e Outlook o Apple Mail e una fonte frequente di confusione, e una che fa perdere molto tempo di troubleshooting agli amministratori.
Perche IMAP APPEND altera le date
Cosa succede durante la migrazione
Quando uno strumento di migrazione sposta un'email dal Server A al Server B, lo strumento si collega al Server A via IMAP e scarica il messaggio grezzo, poi si collega al Server B e utilizza il comando APPEND per inserirlo. Durante questo inserimento, il Server B tratta il messaggio in ingresso e aggiunge un nuovo header Received con il timestamp corrente - la data di migrazione. E il comportamento IMAP standard definito nel protocollo. Il server tratta ogni APPEND come una nuova consegna di messaggio.
Il risultato: una catena di header contaminata
Dopo la migrazione, gli header Received dell'email si presentano cosi:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
L'header Received dello strumento di migrazione e ora la voce piu in alto. Qualsiasi client di posta che utilizza l'header Received piu recente per determinare la data di visualizzazione (Outlook, in particolare) mostrera "11 aprile 2025" al posto di "15 gennaio 2024". L'header Date originale e gli header Received originali sono ancora intatti al di sotto, ma non sono piu nella posizione che i client di posta privilegiano.
Anche una buona gestione dell'INTERNALDATE non impedisce questo
Alcuni strumenti di migrazione impostano correttamente l'INTERNALDATE durante l'APPEND. Ad esempio, imapsync preserva esplicitamente l'INTERNALDATE dal server sorgente. Ma l'header Received viene aggiunto dal server di destinazione, non dallo strumento di migrazione. Lo strumento di migrazione non ha alcun controllo su questo comportamento. Anche con una perfetta preservazione dell'INTERNALDATE, l'header Received piu in alto contiene sempre la data di migrazione, e client come Outlook mostrano comunque la data sbagliata.
Insomma, cosa si puo concretamente fare?
Quali strumenti di migrazione aggiungono header Received
Tutti gli strumenti di migrazione IMAP causano questo problema perche l'header Received viene aggiunto dal server di destinazione, non dallo strumento stesso. Il contenuto dell'header aggiunto varia a seconda dello strumento e del server.
BitTitan MigrationWiz aggiunge un header Received contenente "mx.migrationwiz.com". CloudM Migrate aggiunge header che fanno riferimento a "cloudm.io". imapsync attiva un header Received generico dal server di destinazione. GSMMO aggiunge header con riferimenti a "gmailapi.google.com".
La correzione: ripristinare le date corrette
La buona notizia e che l'informazione di data corretta esiste ancora in ogni email. L'header Date originale e intatto. Gli header Received originali sono intatti. Il problema e che un header contaminante siede sopra di essi.
Il motore di correzione proprietario di Redate.io analizza la catena completa degli header di ogni email coinvolta, applicando una corrispondenza di firme su centinaia di firme di strumenti di migrazione noti per identificare esattamente quali header necessitano di correzione. La pipeline di analisi multistadio gestisce i casi limite che fanno fallire gli approcci piu semplici: messaggi firmati S/MIME, contenuto cifrato PGP, strutture multipart/alternative, problemi di Content-Transfer-Encoding, header non-ASCII (RFC 2047), allegati sovradimensionati e confini MIME corrotti.
Dopo la correzione, ogni email passa attraverso un processo di verifica di integrita per confermare che la struttura, il contenuto e gli allegati del messaggio sono preservati in modo identico. Gli originali sono conservati in una cartella di backup visibile per 30 giorni.
Si potrebbe scrivere uno script per tentare questa correzione da soli? Tecnicamente, si. Ma la differenza tra "funziona sul 95% delle email" e "funziona sul 100% delle email senza corromperne nessuna" rappresenta mesi di sviluppo. E quando si parla della casella di posta completa di qualcuno, un tasso di insuccesso del 5% significa centinaia di messaggi silenziosamente danneggiati senza modo di verificare cosa e andato storto.
Si desidera sapere quante email nella propria casella hanno date sbagliate? Avviate un'analisi gratuita con Redate.io per ottenere un conteggio istantaneo delle email coinvolte, senza alcun pagamento richiesto.