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.


13 risposte a “Perché la mail non viene recapitata?”

  1. Spedisco subito questo post a tutti quelli che, mentre parliamo al telefono, mi mandano mail e chiedono: “Ti è arrivata? NO? Riprova! Adesso ti è arrivata? …” 🙂

      • Eh sì, quelli pure sono una discreta “piaga” lavorativa!
        A completare il quadro ci sono quelli che, quando ti dettano un indirizzo mail, specificano sempre “Tutto maiuscolo, eh!”.
        Ho rinunciato da tempo a spiegare che non fa alcuna differenza…

  2. Per caso volevi far passare il concetto che “la posta elettronica NON è un instant message”?

    No perché mi è sembrato di capire che “la posta elettronica NON è un instant message”.

    Avevo un dubbio che “la posta elettronica NON è un instant message” ma adesso sono sicuro che “la posta elettronica NON è un instant message”.

    Ho già detto che “la posta elettronica NON è un instant message”?

    😀

  3. Aggiungo un commento su “Mail scartata silenziosamente”: purtroppo a me è capitato di incappare in un problema a causa di questo comportamento.

    Alcune aziende hanno adottato come best practice lo scarto silenzioso delle email a indirizzi non validi a causa dell’esacerbarsi degli Directory Harvest Attack.
    Gli attaccanti in genere inviano un gran numero di email a indirizzi generati mescolando nomi e cognomi comuni, scartando gli indirizzi per cui gli MTA restituiscono un errore e deducendo quindi i veri utenti all’interno di una organizzazione. Questo serve poi per portare un attacco mirato: magari tramite tecniche di social engineering, o più semplicemente per ingrassare le liste da vendere agli spammers.

    D’altra parte, questo comportamento porta ad almeno due problemi: supponiamo che io lavori per ACME e abbia un indirizzo valido luca.mauri@acme.com.
    – Se un mittente legittimo manda una email a luca.amuri@acme.com, non riceverà nessun messaggio di errore, ma il MTA scarterà la mail in maniera automatica perché l’indirizzo è errato.
    – Se io lasciassi l’azienda bruscamente e il mio indirizzo venisse cancellato, un mittente legittimo continuerebbe a mandare messaggi al mio indirizzo corretto; messaggi che verrebbero scartati silenziosamente perché l’indirizzo è inesistente.

    In entrambi i casi il mittente crede di aver spedito una email e, non ricevendo messaggi di errore, pensa che tutto sia andato a buon fine, ma all’interno dell’azienda nessuno ha ricevuto le sue comunicazioni.

    Questo tipo di difesa contro i DHA ha pregi e difetti che vanno attentamente valutati.

  4. Ciao, vorrei sapere se l’ordine che ho fatto e rifiutato e stato inoltrato, come faccio a sapere? Grazie

  5. IL MIO è UN CASO CHE NON MI PARE CONTEMPLATO, IN QUESTO POST MOLTO DETTAGLIATO. E che purtroppo non è la prima volta che mi accade. Sono un giornalista, a volte per motivi di tempo, non rientrado subito in ufficio, uso scrivere l’articolo direttamente tramite l’app gmail e poi invio in redazione. E’ quello che ho fatto stamattina, durante una conferenza stampa, durata un paio d’ore. Terminato l’articolo in 40 minuti, digitandolo direttamente sullo Smartphone, ho allegato le goto e dato l’invio. Per un po’ l’ho visto in posta in uscita. Poi di colpo è sparito dalla posta in uscita e non è copmparsa nella posta inviata, sparita del tutto. Dopo altro tempo, è ricomparsa in posta inviata, con tre delle 9 foto allegate, e la dicitura (senza testo). Ovviamente sparito tutto l’articolo e 6 foto su 9.
    Mi chiedo il perchè di ciò e cosa fare per evitare di dover riscrivere tutto d’accapo. Molto complicato, avendolo fatto in presa diretta e senza prendere appunti..
    Grazie, saluti
    Galgano PALAFERRI

    • Ciao, scusa per la risposta tardiva.
      Il tuo caso potrebbe ricadere in un problema di lentezza di trasmissione.
      Il messaggio viene messo nella posta inviata dal server, ma poi il tuo client (lo smartphone) deve riscaricarlo, non lo mette “automaticamente” nella posta inviata.

      Spesso vale la pena di fare una controverifica utilizzando il webmail perchè ci potrebbe stare che il tuo smartphone non ha correttamente sincronizzato la posta

Rispondi a Stefano Petroni Annulla risposta

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *