Come contrastare lo SPAM con SPF, DKIM, DMARC e rDNS

Questa volta proverò a descrivere tutti i problemi che ho avuto con le configurazioni di posta di un CMS che gestisco e le varie soluzioni che ho messo in atto per poterli risolvere. Spero che questo post sia d'aiuto a tutti i sysadmin con problemi simili ai miei

Chi mi conosce sa che nasco come programmatore e non come sistemista, a volte però occorre sporcarsi le mani per risolvere dei problemi legati a configurazioni errate o "troppo leggere" dei nostri server.

Voglio parlarvi di una serie di problemi che ho avuto nella gestione di un piccolo CMS che gestisco e invia giornalmente dalle 4000 alle 8000 email.
Questo valore varia in base ai POST che vengono scritti, agli iscritti alla newsletter giornaliera e a quante iterazioni ci sono fra i vari commentatori.

Il numero è abbastanza variabile, anche se mediamente supera le 4500 email.

La genesi
Quando ho scritto il CMS che ospita anche baccan.it, mandare una email non era un problema. La frequenza era abbastanza ridotta.
Ora la cosa è cambiata, sempre più frequentemente iniziano ad esserci problemi sull'invio delle email.
La casistiche più frequenti sono: email non recapitate e email recapitate in SPAM.

Per questa ragione e per poter dare un servizio migliore, ho iniziato ad analizzare il contenuto delle email inviate, per capire, in dettaglio, quali problemi ci potessero essere nella consegna della posta.

Analisi
Come primo passo ho utilizzato due servizi gratuiti per analizzare le email inviate.

http://isnotspam.com/
https://www.mail-tester.com/

In entrambi i casi si tratta di mandare una email, dai server utilizzati per l'invio della posta, ad un indirizzo fittizio creato per l'analisi del contenuti delle email.
Questa email viene poi analizzata, sia dal punto di vista del contenuto, sia dal punto di vista degli header contenuti nel messaggio stesso.

Non avendo mai curato le qualità delle email inviate, dato che non era alta la loro granularità, avevo tralasciato tutta una serie di operazioni che è buona norma fare quando la lista di destinatari diventa una lista importante e non più un elenco di pochi amici.

Provo quindi ad elencare tutti i problemi che ho trovato e cosa ho fatto per risolverli.

Contenuto dell'email
Il primo problema era relativo ai contenuti dei messaggi. Per poter riuscire ad inviare email in grado di adattarsi al device dove venivano viste (cellulare, pc, tablet), che avessero un aspetto grafico gradevole, mi limitato ad inviarle in HTML.
Non avevo valutato che, in presenza di sistemi di filtraggio come SpamAssassin, le email contenenti solo HTML, potevano avere uno score basso, dovuto alla non presenza del corrispettivo plain text.
Ammetto che non concordo in questa valutazione di SpamAssassin, ma ho comunque deciso di adattarmi, generando delle email multipart, composte sia da testo che da codice HTML, in modo da diminuire la penalizzazione assegnata all'email.

rDNS
Alcune aziende che, per i loro clienti, catalogano email considerate di SPAM, danno molta importanza al reverse DNS del server che effettua l'invio della posta.
Per tale ragione, se il reverse DNS di invio corrisponde ad un server generico e non ad un server di posta, tendono a dare una bassa reputazione all'IP utilizzato per l'invio.
Questo problema mi è capitato con i servizi offerti da Cloudmark, un'azienda che, di lavoro, si occupa di assegnare una reputazione agli ip delle email ricevute da alcuni dei maggiori provider italiani (libero.it, tiscali.it, virgilio.it, teletu.it, iol.it etc).
Ho provato ad affrontare il mio problema di posta con Cloudmark e dopo una serie di accorgimenti, sono stato costretto ad aggiornare il reverse DNS del server utilizzato per l'invio, in modo da non usare un nome di server generico.
Giusto per capire di cosa stiamo parlando, se il reverse DNS del vostro server è qualcosa come

vps9999-94.132.16.224.vps.hosting.tiscali.it

fate in modo di riassegnarlo a qualcosa come

mail.vostroserver.it

in modo da mitigare il problema.
Per sapere il vostro reverse DNS, basta utilizzare un tool online come http://mxtoolbox.com/ReverseLookup.aspx, in grado di visualizzarlo indicando il vostro IP.
Nel mio caso il rDNS era gestito da Tiscali e, tramite i tool web rilasciati per configurare i DNS, non sono stato in grado di cambiarlo.
Ho quindi cambiato provider, acquistando un secondo spazio web dove modificare il rDNS.

Sendmail HELO
Per gestire l'invio della posta, utilizzo sendmail.
Conosco il fatto che ci sono moltissime altre alternative, ma dato che lo utilizzo da anni e ormai mi sono fatto il callo alle sue configurazioni, ho una certa riluttanza a cambiarlo a favore di altri MTA.
Nonostante lo utilizzi da parecchio, mi ero dimenticato di configurare il domain utilizzato per l'HELO verso i server di destinazione delle email :)
Per tale ragione i server venivano contattati col nome macchina, che rappresentava un dato generico, molto simile al precedente rDNS non configurato.
Ho quindi provveduto a cambiare l'HELO nel file sendmail.mc, aggiungendo la stringa corretta, corrispondente al rDNS.

SPF
Uno dei meccanismi di protezione dei server di invio della posta è dato dalla configurazione di un DNS in grado di indicare da quali IP è ammesso inviare posta e come comportarsi in caso che l'invio non avvenga da questi indirizzi.
Ho trattato questo argomento in un altro post di questo BLOG: Come evitare che le email inviate finiscano in spam.
Questa tecnica permette ai server che ricevono dei messaggio di posta, di scartare automaticamente le email ricevute da IPV4 o IPV6 non ammessi nel record SPF del dominio del sender.
Capisco che il giro potrebbe essere un po' complicato a spiegarsi, ma in pratica si tratta solamente di aggiungere un record al DNS di tipo SPF o TXT al vostro dominio. Fatto questo, potrete aiutare i server a decidere se, le email che ricevono, sono inviate da macchine autorizzate.

DKIM
Esistono casi in cui si desidera dare una certezza di non modificabilità all'email che viene inviata. Chiaramente poter garantire questa informazione aiuta i mail server a decidere se l'email è da considerarsi "sicura" o "modificata" e di conseguenza a prendere delle scelte sul fatto di conservarla o scartarla.
L'implementazione del DKIM è leggermente più complessa rispetto a un SPF. Si è infatti obbligati a generare una coppia di chiavi (pubblica e privata), che servono a dare una firma ai messaggi.
Per quanto riguarda la chiave privata, deve essere utilizzata dal programma che gestisce il DKIM (per esempio opendkim) che riceve in ingresso copia dell'email, ne calcola la firma, e l'aggiunge come parametro all'header dell'email (DKIM-Signature).
La chiave pubblica viene invece inserita in un apposito record di DNS del dominio che invia la posta.
In questo modo, il server ricevente ha in mano una firma in header e un apposito record di DNS, per verificare la bontà della firma.
Opendkim, essendo un demone che risponde via socket, deve poi essere interfacciato da Sendmail (nel mio caso), in modo da poter svolgere il proprio lavoro di arricchimento dell'email.
Questa operazione aggiunge però un piccolo overhead all'invio della posta. Nel mio caso ha quasi raddoppiato i tempi di invio dei singoli messaggi.

dmarc
Una volta che è stato implementato SPF e DKIM è possibile indicare, tramite un altro record di DNS, dove inviare eventuali report di SPAM, indicanti da quali IP vengono inviate email che non rispettano SPF o DKIM.
Questa ultima accortezza permette, agli amministratori dei server di posta, di capire se c'è un problema di configurazione o se un particolare IP manda email aventi come mittente il dominio sotto la vostra gestione.
Una volta configurato il dmarc si riceveranno, con una cadenza periodica, report da parte dei maggiori provider, rispetto alle statistiche di ricezione di email provenienti dal dominio relativo al dmarc.

Conclusioni
Queste sono state le prime modifiche che ho apportato alla configurazione delle liste di email che gestisco. Dai primi test sembra che stiano dando i loro benefici, aumentando il numero di email consegnate.
Vedremo, nelle prossime settimane, se i benefici continueranno o i miei utenti torneranno ad avere problemi di invio della posta.
Vi terrò aggiornati per eventuali sviluppi.

Conosco il fatto che l'alternativa a tutto questo lavoro è data dall'appoggiarmi ad un servizio di invio posta come MailChimp, MailUp o simili, ma quando si gestiscono dei server con servizi gratuiti, o comunque dei servizi di clienti che non intendono passare ad un servizio esterno, (anche se a buon mercato) può essere una buona pratica avere un servizio realizzato a regola d'arte, dal basso costo.

Giusto per avere un'idea, i costi attuali del server di invio posta, si aggirano sui 25 euro/anno. Credo comunque passerò ad un server virtuale più potente, passando a circa 50 euro/anno, una cifra che mi sembra più che accettabile per inviare oltre 2.000.000 di email, tenendo conto che utilizzo circa 1 ora al giorno il server, le restanti 23 ore la macchina è praticamente ferma. Leggi QUI il post completo