Perché la mail non viene recapitata?

Spesso gli utenti si chiedono come mai i loro messaggi di posta elettronica rimbalzino o non vengano recapitati istantaneamente ai destinatari.

Chiariamo subito un concetto base: la posta elettronica NON è un instant message.

Un messaggio di posta elettronica una volta uscito dal client può trovarsi in questi stati: in transito, in coda, recapitato, rimbalzato, scartato silenziosamente. 

Per capire come le cose possono andare male è necessario capire come possono andare bene.

Un messaggio viene redatto dal client (Outlook, Thunderbird, K9, webmail) e trasferito al server (MTA) tramite un protocollo proprietario oppure tramite il protocollo SMTP. L’MTA utilizza il DNS per vedere qual è il mail exchanger (MX) preferenziale del destinatario, lo contatta in SMTP sulla porta 25 e gli trasmette il messaggio. L’MTA del destinatario, ricevuto il messaggio, lo incasella nella mailbox dell’utente, il quale lo preleverà con IMAP, POP o con un protocollo proprietario. Il messaggio può passare attraverso più MTA prima di raggiungere la destinazione. Se il messaggio è ragionevolmente breve, se i server non sono intasati e se le linee sono preformanti il tutto avviene in una manciata di secondi.

Se la manciata di secondi diventa una manciata di minuti o di ore non è un problema dal punto di vista tecnico di funzionamento perché la posta elettronica NON è un instant message.

Di seguito si fa riferimento a due classi di errore: 4xx (temporaneo, riprova a mandare il messaggio più tardi) e 5xx (fatale, non riprovare ad inviare il messaggio). Le due classi servono ad indicare al MTA mittente come si deve comportare in merito al messaggio che sta tentando di spedire: in linea generale un codice 4xx lascerà il messaggio in coda, un codice 5xx lo rimbalzerà al mittente.

Ci sono dei fattori che ritardano o impediscono il flusso di un messaggio dal mittente al destinatario, vediamo qui quali sono e come reagire, se è il caso di reagire.

Mail in transito

Se una mail con scritto solamente “ok, va bene” viene recapitata in pochi secondi, non è detto che una mail dallo stesso mittente al medesimo destinatario venga recapitata nello stesso tempo se questa contiene un allegato di qualche megabyte. A parte la differenza materiale di dimensione, bisogna calcolare il fatto che ogni contenuto non testuale come allegati e immagini viene codificato generalmente in Base64, che aumenta di circa il 37% la dimensione dei dati. A questo si aggiunge il fatto che non siete gli unici ad usare Internet, quindi i server possono essere occupati anche a fare altro. Tutte questi (ed altri) fattori sommati fanno in  modo che la mail possa impiegare decine di minuti se non ore per essere recapitata, ma è una cosa normale perché la posta elettronica NON è un instant message. Portate pazienza.

Mail ferma in coda

Per evitare di sovraccaricare la linea e per un corretto utilizzo delle risorse, ogni MTA ha dei valori massimi per i vari tipi di coda (esistono varie code negli MTA, il numero e la funzione varia a seconda dell’MTA e della configurazione). Un MTA può decidere di limitare il numero di messaggi da recapitare contemporaneamente e mettere in coda gli altri, che vengono elaborati non appena un messaggio viene recapitato; pensate come analogia ai check-in degli aeroporti in cui esiste un’unica coda di passeggeri in partenza servita da più operatori.
Anche l’MTA remoto potrebbe avere delle limitazioni di code mail in ingresso, quindi potrebbe rispondere con un errore 4xx nel caso in cui stia ricevendo il numero massimo di mail contemporanee previsto dal SysAdmin. Il questo caso l’MTA del mittente riceve un errore 4xx con una descrizione tipo “Server too busy” e rimette in coda il messaggio per un recapito futuro.
Gli errori 4xx possono capitare anche per altre ragioni, tra le quali disco pieno del server remoto, mailbox del destinatario che ha superato la quota limite o greylisting. Anche un errore temporaneo di accesso al DNS o l’impossibilità di contattare il server del destinatario mette la mail in coda.
Generalmente il lookup positivo su un RBL provoca un errore 4xx, questo è forse l’unico caso serio in cui il SysAdmin del mittente deve intervenire per risolvere la situazione.
Tutte le mail restano in coda in uscita per un tempo massimo fissato dal SysAdmin, che di solito non è meno di 48 ore. L’MTA dopo qualche ora (generalmente 4) che la mail è in coda in uscita notifica il mittente con un messaggio di avviso. Generalmente gli MTA riprovano a recapitare i messaggi in coda con frequenze sempre più rilassate: più di frequente nei primi momenti e meno di frequente man mano che la permanenza si allunga. Scaduto il tempo massimo di permanenza, il messaggio viene rimbalzato al mittente.
In ogni modo, la mail ferma nella coda in uscita fa parte del gioco e non è un errore perché la posta elettronica NON è un instant message.

Mail rimbalzata

La mail viene rimbalzata con un errore fatale 5xx e, a meno di code o ritardi, il rimpallo avviene entro pochi minuti dall’invio.
Il motivo più comune per un rimbalzo è che l’utente non esiste (più); può succedere che il mittente sbagli a scrivere il nome del dominio e tenti di inviare una mail a pippo@gmail.it oppure pippo@gimail.com; in questo caso l’errore sta dopo la chiocciola e si riceve un errore 5xx di utente sconosciuto. Quando si riceve un errore di tipo “utente sconosciuto” è sempre bene rileggere con attenzione cosa si è scritto nel campo del destinatario prima di chiamare il supporto tecnico.
Un altro errore 5xx tipico è un contenuto non ammesso (come un allegato eseguibile), un allegato troppo grosso oppure un messaggio rifiutato come presunto SPAM. Se si vogliono inviare allegati corposi e specialmente se li si invia a più destinatari l’ideale è metterli online sul sito aziendale oppure su un servizio come Dropbox o SpiderOak e inviare al destinatario l’URL per scaricare il file.
Il server destinatario potrebbe decidere di rifiutare le mail di un MTA se non soddisfa regole che lui stesso ha deciso in autonomia, in questo caso il SysAdmin del MTA mittente dovrà trovare le contromisure per poter recapitare la mail al destinatario schizzinoso.
Ogni mail rimbalzata viene segnalata con un messaggio di notifica chiamato in gergo NDR (Non Delivery Report).

Mail scartata silenziosamente

È un caso raro, ma può capitare che il server destinatario cancelli la mail senza recapitarla e senza generare un NDR. Questo caso si verifica quando l’amministratore dell’MTA destinatario ha configurato il server per adottare questo comportamento in base a regole impostate. Questo è un caso diverso dalla mail che finisce per errore nella casella dello spam, in quanto in questo caso si tratta di un messaggio correttamente recapitato a livello SMTP, ma finito in un’altra casella per iniziativa del client (o dell’utente).
Si tratta, in ogni modo, di un caso molto raro che non mi è capitato negli ultimi anni; generalmente i SysAdmin degli MTA impostano questa regola su messaggi palesemente spammosi oppure su mittenti molesti.

In sostanza, se una mail rimbalza la prima cosa da fare è cercare nel messaggio diagnostico (purtroppo spesso sono oscuri per gli utenti) dove sta il motivo del mancato recapito e cercare di agire di conseguenza.

L’importante è non allarmarsi se la mail non viene recapitata immediatamente e non si ricevono messaggi di errore perché, è bene ricordarlo, la posta elettronica NON è un instant message.