Problemi nell’inviare e ricevere mail. Guida di riferimento alla diagnosi e alla risoluzione.

Capita a volte che nell’invio di una mail si abbia come risultato il mancato invio o la mancata ricezione. del messaggio. Capire in realtà quale dei due casi ci troviamo di fronte non è facile appunto, perchè in entrambi i casi stabilire se ci troviamo di fronte ad un mancato invio o ad una mancata ricezione è difficile e richiede indagini a livello tecnico non sempre possibili da parte dell’utilizzatore finale.

Di chi sarà la colpa dunque ? Del mittente o del destinatario ?

Va premesso che l’invio di una mail e la sua ricezione comporta una serie di operazioni “dietro le quinte” assolutamente non banali che determinano in modo indiscutibile l’esito positivo o meno dell’invio e della ricezione.

Sebbene l’invio di una mail sia alla portata di tutti è anche vero che esistono migliaia di mailserver ognuno col proprio software e ognuno con la propria configurazione che a volte possono non comunicare tra loro per problemi di natura tecnica e di errata configurazione.

Ipotizziamo uno scenario reale

Quando un utente, ad esempio tizio@tizio.it, prova ad inviare una mail a un altro utente, come caio@caio.it, si attiva una serie di operazioni tecniche ben precise che avvengono in background. Queste operazioni sono regolamentate da protocolli standardizzati e orchestrate da più componenti, pur apparendo all’utente come una semplice azione di invio tramite un clic.

1. Il client di posta elettronica utilizzato da tizio, che può essere un software come Outlook, Thunderbird o una webmail, si connette al mailserver responsabile della gestione delle email in uscita per il dominio tizio.it, ad esempio mail.tizio.it. La connessione avviene generalmente tramite il protocollo SMTP, autenticato e sicuro, usando le porte 587 (submission) o 465 (smtps). Una volta stabilita la connessione, il client trasmette al server tutte le informazioni necessarie alla composizione della mail: mittente (MAIL FROM), destinatario (RCPT TO), intestazioni come Subject, ed infine il corpo del messaggio (DATA), seguendo fedelmente la sintassi prevista dal protocollo SMTP.

2. Una volta completato l’invio dal client al mailserver mittente, questo – che è un software in ascolto sulla porta 25, specializzato nella gestione e inoltro delle email – passa alla fase successiva: individuare il mailserver di destinazione. Per farlo, effettua una richiesta DNS (Domain Name System) cercando il record MX (Mail Exchanger) del dominio del destinatario, in questo caso caio.it. Questo record indica quale server è autorizzato a ricevere la posta per quel dominio.

3. Il DNS per il dominio caio.it risponderà con il nome del mailserver autoritativo, ad esempio mail.caio.it. Il mailserver mittente, quindi mail.tizio.it, userà questa informazione per instaurare una connessione TCP verso la porta 25 di mail.caio.it. Una volta stabilita la connessione, il server tizio inoltrerà la mail in coda, precedentemente ricevuta dal client dell’utente tizio@tizio.it.

4. Il mailserver di destinazione, mail.caio.it, riceve il messaggio e lo colloca nella coda di posta in ingresso. In questa fase, il server si occupa di conservare il messaggio all’interno del filesystem locale, in un formato strutturato che può essere Maildir (basato su directory e file separati per ogni messaggio) oppure mbox (file unico contenente tutte le email). Il messaggio viene quindi associato all’account caio@caio.it, pronto per essere consultato dal destinatario.

5. Infine, il destinatario – in questo caso caio – utilizzerà il proprio client di posta per accedere al messaggio appena ricevuto. Questo avviene tramite un protocollo di posta in ingresso, POP3 o IMAP, che permette rispettivamente di scaricare il messaggio sul dispositivo o di consultarlo lasciandolo sul server. Una volta stabilita la connessione al server di posta in entrata, il messaggio verrà letto e reso disponibile all’utente.

Questo è quello che avviene in un regime normale, ovvero senza controlli specifici antivirus e antispam.

Già fino ad ora, per far funzionare tutto questo meccanismo, si ha bisogno dei seguenti requisiti:

• 2 mailserver pienamente funzionanti, uno per il mittente e uno per il destinatario

• Le informazioni host ed IP sui mailserver siano pubblicati nelle voci DNS (dette zone) dei domini in questione

• Effettuare una query DNS implica il fatto di avere un server DNS funzionante con le corrette informazioni pubblicate, in particolar modo il record MX

Configurazioni avanzate con controlli sul mittente e sul contenuto.

In una configurazione avanzata, si ha a che fare inoltre con controlli aggiuntivi, implementati lato mailserver, che svolgono un ruolo fondamentale nel filtrare il traffico in entrata e difendere l’infrastruttura da spam, malware e tentativi di abuso. Questi meccanismi non solo migliorano la sicurezza e l’affidabilità della posta elettronica, ma permettono anche di mantenere una buona reputazione dei mailserver coinvolti.

Greylisting: è una tecnica di difesa molto efficace e semplice da implementare. Quando un messaggio viene ricevuto da un mittente sconosciuto (in base alla combinazione IP, mittente e destinatario), il server destinatario rifiuta temporaneamente la mail con un codice SMTP “try again later”. Questo comportamento, che potrebbe sembrare controproducente, sfrutta in realtà una debolezza tipica degli spam bot: questi strumenti automatizzati tentano di inviare grandi volumi di messaggi e non gestiscono correttamente i rinvii temporanei. I server SMTP legittimi, invece, come da specifica RFC, riproveranno a inviare il messaggio dopo alcuni minuti. Questo permette di effettuare una prima e già significativa selezione tra traffico lecito e traffico malevolo. Il principale svantaggio di questo approccio è il ritardo nella ricezione della prima mail da un determinato mittente, che può variare da 10 a 15 minuti o anche di più, specialmente se il server mittente è lento nella gestione delle code di retry. Dopo la prima consegna andata a buon fine, però, il mittente viene “whitelistato” temporaneamente o permanentemente, velocizzando i successivi invii.

DNSBL (DNS-based Blackhole List): è un altro potente strumento di difesa. Quando un mailserver riceve una connessione in entrata, effettua una serie di query verso liste pubbliche e distribuite su internet che contengono indirizzi IP noti per attività di spam o comportamento sospetto. Queste richieste sono simili a quelle fatte per ottenere record DNS e vengono effettuate tramite protocollo UDP. Se l’IP del mittente compare in una di queste blacklist, il messaggio può essere automaticamente respinto, restituendo al mittente un messaggio di errore contenente il motivo del rifiuto. Questo approccio permette di bloccare in modo proattivo grandi quantità di posta indesiderata, ma richiede un’attenta selezione delle liste da utilizzare per evitare falsi positivi e limitare l’impatto su email legittime.

SPF (Sender Policy Framework): è un meccanismo di validazione che consente al dominio del mittente di specificare, tramite appositi record TXT nel DNS, quali indirizzi IP o host sono autorizzati a inviare email per conto di quel dominio. Quando un server riceve un messaggio, può eseguire una verifica SPF per assicurarsi che l’IP mittente sia effettivamente incluso in questa lista. In caso contrario, la mail può essere contrassegnata come sospetta o respinta. Lo SPF è molto utile per contrastare lo spoofing, cioè l’invio di email con indirizzi mittenti falsificati, e rappresenta una prima barriera contro il phishing e lo spam. Tuttavia, lo SPF non protegge il contenuto del messaggio né garantisce che la mail non sia stata alterata lungo il percorso.

DKIM (DomainKeys Identified Mail): è una tecnologia di autenticazione che permette a un’organizzazione di firmare digitalmente i messaggi in uscita. La firma, generata tramite una chiave privata, viene inserita all’interno dell’header del messaggio. Il destinatario, a sua volta, può verificare l’autenticità del messaggio e la sua integrità utilizzando la chiave pubblica pubblicata nel DNS del dominio del mittente. DKIM garantisce che il messaggio non sia stato modificato in transito e certifica che provenga realmente da chi dichiara di averlo inviato. Questo meccanismo non è visibile all’utente finale, perché la verifica viene gestita direttamente dal mailserver ricevente. A differenza della crittografia end-to-end, che protegge il contenuto da occhi esterni, il DKIM è focalizzato sull’autenticità del mittente e viene utilizzato dai provider per prendere decisioni sul trattamento del messaggio in termini di fiducia.

Antispam / Antivirus: una volta superati i controlli precedenti, il messaggio viene analizzato in base al contenuto. I sistemi antispam moderni assegnano un punteggio ad ogni mail ricevuta, valutando fattori come la presenza di parole chiave sospette, allegati pericolosi, pattern tipici dello spam, URL interni, lingua utilizzata, reputazione dell’IP mittente e molto altro. Se il punteggio supera una certa soglia (solitamente 5), il messaggio viene classificato come SPAM. In base alla configurazione del server o del filtro lato client, il messaggio potrà essere spostato automaticamente nella cartella SPAM, oppure potrà essere consegnato normalmente ma con una modifica dell’oggetto, ad esempio anteponendo etichette come [SPAM] o ***SPAM***.

In questo caso, affinché il messaggio venga ricevuto correttamente dall’indirizzo del destinatario, il mittente deve garantire una serie di buone pratiche fondamentali. Prima di tutto, l’IP del mailserver mittente non deve essere elencato in una DNSBL. Inoltre, il messaggio deve essere strutturato correttamente: è indispensabile scrivere un oggetto coerente, includere un corpo testuale leggibile (evitando HTML puro con una sola immagine, ad esempio), ed evitare allegati potenzialmente dannosi o proibiti, come eseguibili .exe, script .bat, .vbs, o file compressi sospetti. Ogni anomalia può aumentare il punteggio SPAM e comprometterne la consegna.

Va inoltre sottolineato con chiarezza un concetto troppo spesso sottovalutato: quando una mail non arriva a destinazione, o non viene ricevuta, la responsabilità può ricadere tanto sul mittente quanto sul destinatario. È errato presumere che il colpevole sia sempre “chi la aspetta”. Se, ad esempio, un nostro cliente o fornitore ci invia una mail da un server elencato in una blacklist DNSBL, la responsabilità è totalmente sua: è lui a non inviare la posta secondo le regole minime di igiene SMTP. Il nostro server, nel rifiutare quella mail, sta facendo esattamente ciò che dovrebbe fare: proteggere la nostra infrastruttura da fonti potenzialmente malevole.

È importante anche ricordare che la posta elettronica non è, e non è mai stata, uno strumento pensato per la comunicazione istantanea. La sua architettura è asincrona e best-effort: la consegna non è garantita, non è immediata e può essere soggetta a ritardi o errori. Qualsiasi uso della mail come sistema “real-time” è, tecnicamente, un uso improprio.

Ogni volta che una mail non viene recapitata, il sistema mittente (a meno che non sia stato mal configurato) restituisce un messaggio di errore, detto bounce, che include un codice SMTP e una descrizione del problema. Leggere questi messaggi di errore con attenzione consente, senza ombra di dubbio, di comprendere l’origine del problema: se è un nostro blocco, se è un errore del mittente, se l’indirizzo non esiste, o se il messaggio è stato respinto per motivi di sicurezza.

Troppe volte questi errori vengono ignorati o trascurati, e si finisce per segnalare come guasti problemi che in realtà sono semplicemente legati al rispetto (o meno) delle regole. Basterebbe prendersi qualche minuto per leggere il contenuto del bounce per evitare comunicazioni inutili o infondate all’helpdesk aziendale.