La dura vita di una email

Ero abituato bene, con il mio Mailman su di un computer universitario: premevo invia, e partiva la newsletter destinata a 4000 iscritti. Per carità, succedeva di rado, ma quando serviva, sapevo che lui era là, pronto a riprovare l’invio per ben 5 giorni, per qualunque destinatario il cui provider facesse i capricci. Ora che sono passato ad un hosting privato, le cose si sono complicate abbastanza, e per spiegarne il motivo, devo illustrare un pò quel che succede. Ma alla fine del post, potete trovare la soluzione che ho adottato!

La situazione attuale

Sono passati 36 anni da quando è stata pubblicata la RFC 821 che per prima ha definito il meccanismo di recapito di una email, che essenzialmente si svolge ad opera di due server SMTP,  mittente e destinatario. Da allora la rete è divenuta piena di insidie, e le nostre mailbox traboccano di annunci, newsletter, pubblicità, ed oltre alle varie cose a cui diamo distrattamente consenso, arriva sempre qualche truffa, finta bolletta o fantomatica vincita miliardaria. Fino a qualche anno fa queste email farlocche venivano prevalentemente diffuse tramite programmi-virus che infettavano i computer personali, mentre al giorno d’oggi partono da server ben carrozzati e appositamente preposti allo scopo, ed usano come mittenti indirizzi email di fantasia, oppure realmente esistenti.

Come si comportano i provider

Si è innescata allora tra i provider di caselle email una doppia spirale di contrasto al fenomeno:

• l’SMTP mittente adotta meccanismi volti a mantenere una buona reputazione, come l’SPF (Sender Policy Framekork) mediante il quale vengono dichiarati quali siano gli indirizzi IP legittimati ad inviare email provenienti da un certo @dominio.it, e come il DKIM (Domain Key Identifyed Mail) in grado di certificare di essere i mittenti reali delle email;
• l’SMTP ricevente sceglie se rifiutare o meno le email in arrivo consultando elenchi on-line (Blacklist) che contengono gli indirizzi IP che sono stati segnalati come origine di spam, e quindi filtra le email accettate attraverso programmi (es. SpamAssassin) che applicano ulteriori criteri per classificarle come spam o meno;
• dato poi che fidarsi è bene ma non farlo è meglio, qualora l’SMTP di destinazione riceva una email proveniente da un mittente mai visto prima può attuare una strategia di Greylisting, ovvero inviare un codice di risposta di fallimento temporaneo, (4xx) che invita il mittente a riprovare più tardi. Lo stesso può accadere se si accorge che un certo SMTP mittente invia email troppo velocemente, al punto da sospettarlo come compromesso, ed in tal caso segnalarlo per essere inserito in qualche Blacklist.

Il problema aggiuntivo dell’hosting condiviso

In questo caso, che è il mio, un medesimo SMTP mittente spedisce posta per tutto un insieme di clienti (e domini) diversi. Se uno di loro si comporta male, può causare il blacklisting dell’intero server condiviso, penalizzando anche gli altri utilizzatori. Il provider allora stabilisce limiti di invio, come il massimo numero di email ed il massimo numero di errori per ora. Il meccanismo però, anche se del tutto ragionevole, inizia a divenire perverso quando venga definito errore, oltre all’invio verso un destinatario inesistente, anche una risposta di fallimento temporaneo dovuta a greylisting. In caso di sforamento (che per il mio provider è di 5 errori/ora!) il dominio mittente viene bloccato, e tutti i messaggi spediti nell’ora successiva vengono semplicemente rifiutati.

L’ultimo tassello del problema è che la newsletter viene inviata a tutti i destinatari mediante un software automatico (phplist), che non distingue bene il tipo di errore, per cui anche in presenza di un blocco dovuto a troppi errori (e subire più di 5 ritardi a causa di greylist è assolutamente normale!) non solo continua a tentare gli invii, ma tutti i successivi errori dovuti al blocco sono interpretati come destinatari inesistenti, causando la cancellazione delle rispettive email di destinazione dai successivi invii. In pratica, l’errore temporaneo si è trasformato in errore definitivo!!

Dopo avere esposto il problema al mio provider, la sua proposta è stata quella di richiedere un IP dedicato, che cioè andrebbe a gestire solo le email del mio dominio, e dunque non avrebbe i problemi legati alla difesa di una reputazione condivisa. Peccato che una soluzione del genere costi ben di più del piano di hosting che sto usando!

Sulla strada della soluzione

Allora mi sono messo in cerca, ed ho trovato un servizio (Mailgun) che offre ben 10.000 email/mese gratis, e dovendone spedire di più, si può pagare a consumo. Non è meraviglioso? La lista di email a cui spedire la mia newletter, che ho accumulato in più di dieci anni, è di 4000 indirizzi, ce la faccio benissimo! Però… neanche Mailgun è esente dalle problematiche di reputazione, per cui a sua volta pone un limite di non più del 5% di email errate o inesistenti, anche se per fortuna non conta come errori quelle ritardate a causa di Greylist. Ed è più che normale che molte delle email che ho collezionato in tanti anni non esistano più.

La bonifica delle email inesistenti

Ancora una volta, ho trovato la strada grazie ad una ricerca Internet che, oltre ad alcuni servizi on-line come Hippo e Tester, mi ha condotto ad uno script in grado di verificare autonomamente se una email esiste o meno, senza doverla necessariamente spedire. L’ho modificato un po’ per permettermi di usarlo su di un intera lista di email, e con questo post ne condivido con voi la sua versione attuale, mediante la quale gestire anche la problematica del greylisting, semplicemente ripetendone l’esecuzione per i soli indirizzi a cui viene risposto con un codice di fallimento temporaneo. In questo modo ho in pratica dimezzato il mio elenco iniziale!

Foto di Marius Christensen su Unsplash