Già in un mio post precedente ho descritto come sia importante impostare correttamente un record SPF associato al dominio di posta per evitare (o ridurre) il rischio di vedere la propria posta elettronica in uscita categorizzata come SPAM dai filtri automatici a protezione delle mailbox dei destinatari.

In questo nuovo articolo estendiamo l’analisi del problema per tutti coloro che, gestendo direttamente un dominio proprio, utilizzano anche il BlackBerry per la propria posta in mobilità. E’ noto che per ricevere/inviare posta dal proprio telefonino BlackBerry sia necessario attivare uno di questi due servizi:

• BIS – BlackBerry Internet Service : sicuramente l’opzione più diffusa, grazie anche al bundle offerto dai numerosi carrier
• BES – BlackBerry Enterprise Server : per una sincronia completa delle mailbox

La distinzione di questi due servizi non è solo importante per le caratteristiche differenti (BIS sincronizza solo la posta mentre con BES si sincronizza tutto – email, contatti, task, memo ecc), ma anche per il modo in cui la posta in uscita dal nostro telefonino viene recapitata. Infatti mentre gli utenti BES utilizzano come trasporto SMTP quello aziendale ovvero il medesimo che utilizza il normale client di posta del computer di rete, quelli invece che hanno la posta BB configurata in modalità BIS inviano i messaggi utilizzando i server Blackberry.

Pertanto, per questa seconda categoria di utenze, è necessario che il gestore del dominio di posta si occupi di integrare all’interno del record SPF anche le informazioni relative ai server BlackBerry che il telefonino usa per inviare. A questo proposito Research In Motion ha approntato diversi puntamenti che definisicono il range di server SMTP che possono essere utilizzati dai telefonini.

Per gli utenti Europei è necessario integrare il record SPF con la seguente direttiva :

include:srs.bis.eu.blackberry.com

In questo modo un esempio di record SPF può essere il seguente :

"v=spf1 a mx include:srs.bis.eu.blackberry.com -all"

Questa notazione significa : considera attendibili tutte le mail associate al dominio che hanno come indirizzi IP di mittenza un qualsiasi record A associato al dominio, oppure che provengano da un server di posta autoritativo per il dominio o, ancora, che siano state inviate da un server BlackBerry europeo.

Sappiamo tutti quanto stia diventando intrusiva la pubblicità che troviamo inserita a forza nelle pagine dei siti internet durante la normale navigazione. Ma se il singolo utente la considera più una seccatura (alla stregua della pubblicità che interrompe il programma televisivo preferito), per gli amministratori di rete diventa anche un problema tecnico: le pagine richieste dagli utenti della rete, con le loro continue inclusioni di banner, script ed immagini di varia natura, succhiano banda riducendo, per tutti, le risorse disponibili. Senza contare che, in genere, gli utenti, sapendo di essere protetti da un gateway aziendale, cliccano qua e là senza curarsi troppo della sicurezza e della miriade di informazioni di profilazione che vengono raccolte. Insomma, attivare una linea di difesa contro l’intrusione della pubblicità, aumenta non solo la sicurezza ma anche la velocità complessiva di navigazione.

Intendiamoci : non mi ritengo un integralista che ha deciso di abbattere il modello di revenue più diffuso sul web e, parimenti, sono convinto del fatto che per molte iniziative sia forse l’unico modello di sostentamento possibile. Ma certamente alcuni siti esagerano davvero esprimendo contenuti originali che, in rapporto alla pubblicità, stanno a 10Kb contro 200Kb o più. Animazioni, spesso ridondanti, pop-up automatici, immagini a tutto schermo ecc.

Esistono diversi motivi per approcciare la soluzione del problema: da quelli squisitamente personali (un esempio ne è l’eccellente AdBlock Plus per Mozilla Firefox) fino a sistemi di protezione a livello di gateway aziendale.

In questo articolo vedremo come configurare SQUID in modo che possa validamente aiutarci in questo scopo. Alla data di scrittura di questo documento ci occuperemo di come configurare Squid 2.6 su una distribuzione CentOS 5.4 (ovviamente do per scontato che già tutti i client della vostra rete possano navigare solo per il tramite del proxy).

Probabilmente già molti di voi sono a conoscenza del fatto che tra le moltissime direttive offerte dal file di configurazione di Squid è possibile impostare delle ACL (Access Control List) che, con opportuni filtri basati su espressioni regolari, ci consentono di creare dei divieti (deny) allo scaricamento di contenuti provenienti da specifici indirizzi (URL). Il rovescio della medaglia di questa tecnica è che, una volta individuate le origini dei contenuti da bloccare, chi naviga può vedersi comporre delle pagine con diversi riquadri che riportano informazioni di errore. Ed ecco che entra in gioco una eccellente caratteristica di Squid: la caratteristica di redirection delle richeste.

La redirection (o rewrite se preferite) utilizza uno script che dice a Squid di tenere d’occhio degli specifici indirizzi (URL) nelle richieste che riceve (per esempio ad.doubleclick.com). Quando un browser della rete inoltra una richiesta con questo URL a Squid, lo script reindirizza la richiesta ad un file locale, come ad esempio una immagine gif che contiene solo un pixel trasparente. E siccome questa richiesta in realtà non esce mai dalla rete locale, l’intera navigazione risulterà estremamente veloce oltre all’indubbio beneficio dato dal fatto che là dove ci si aspetta di trovare un bel banner animato, non vedremo (o meglio, gli utenti non vedranno) assolutamente nulla.

Ma come fare tutto questo ? E’ molto semplice … avete bisogno di tre cose :

1. Squid … ovviamente installato e funzionante
2. Un web server interno alla rete aziendale (che sia IIS o Apache non importa)
3. Squid.redir … un piccolo script ideato e mantenuto da Craig Sanders che potete scaricare direttamente da questo link

Ecco come procedere all’installazione :

1. Accedete alla shell console del vostro server Linux (CentOS per me)
2. Create una directory di lavoro sotto la vostra home : mkdir ~/squid.redir [Enter]
3. Accedete alla directory appena creata e scaricate il pacchetto che contiene lo script:
   wget http://taz.net.au/block/squid-redir.tar.gz [Enter]

4. Estrate i file contenuti nell’archivio :
   tar -xzvf squid.redir.tar.gz [Enter]

5. Verranno estratti i seguenti file : closeme.html, do_nothing.js, dot.gif, gen.squid.redir, Makefile, README, redir
6. Cancellate il file gen.squid.redir appena estratto e sostituitelo con quello che trovate qui : gen.squid.redir
   rm -f gen.squid.redir [Enter]
wget http://www.anlan.com/upload/gen.squid.redir [Enter]

7. Copiate i seguenti file nella directory /usr/lib/squid: con privilegi di superuser eseguite i seguenti comandi:
   cp Makefile /usr/lib/squid
cp gen.squid.redir /usr/lib/squid
cp redir /usr/lib/squid

8. Copiate i seguenti file nella web root di un vostro webserver interno alla rete.
   closeme.htm (verrà sostituito ai pop-up)
   do_nothing.js (per sostituire gli script come ad esempio quelli dei contatori dei siti)
   dot.gif (un’immagine trasparente di un solo pixel)
   
9. Ora accedete alla cartella/libreria di squid : cd /usr/lib/squid [Enter]
10. Con un editor di testo (io uso nano) aprite il file gen.squid.redir (quello scaricato al punto 6 e copiato al punto 7). Individuate la seguente riga:
    $BASE_URL=”//YOUR-WEB-SERVER-HERE”;
    e sostituite YOUR-WEB-SERVER-HERE con l’indirizzo IP oppure il nome di host del web server in cui avete copiato i file al punto 8. Se per esempio il vostro webserver risponde all’indirizzo IP 192.168.1.4 allora dovrete modificare la riga in questo modo:
    $BASE_URL=”//192.168.1.4″;
    Dopo aver effettuato la modifica salvate il file e chiudete l’editor.
11. Ancora con l’editor aprite ora il file redir. Noterete che vi sono già diverse righe compilate. La sintassi del file è molto semplice. Ogni riga è divisa in due da uno o più caratteri di tabulazione. Nella parte di sinistra trovate la regular expression che deve essere ricercata all’interno dell’URL richiesto e nella parte destra, se si verifica una corrispondenza, la variabile che contiene l’indirizzo da ritornare a squid. Le variabili possibili sono 4 :
    • $1 -> ritorna lo stesso indirizzo senza modifiche
    • BLANK -> ritorna l’URL in cui, presso il TUO webserver, si trova l’immagine dot.gif
    • CLOSEME -> ritorna l’URL in cui, presso il TUO webserver, si trova il file closeme.html
    • NULLJS -> ritorna l’URL in cui, presso il TUO webserver, si trova il file do_nothing.js

    In pratica funziona così: squid riceve una richiesta da un browser della rete, passa la richiesta al programma di reindirizzamento che stiamo preparando, e quest’ultimo lo confronta con le espressioni regolari inserite. Se trova una corrispondenza ritornerà a squid l’URL “corretto” in modo che non venga inviata una richiesta ad internet ma solo una richiesta al web server per recuperare il file “fantasma”.

12. Chiudete pure ora il file redir
13. Aprite ora il file di configurazione di squid (per CentOS o RedHat si trova in /etc/squid/squid.conf): cercate il tag url_rewrite_program. Dopo esservi letti bene la spiegazione di questo tag attivatelo inserendo una riga non commentata:
    url_rewrite_program /usr/lib/squid/squid.redir
    salvate il file e chiudete.
14. Tornate ora alla directory /usr/lib/squid. Digitate make e premete invio. La procedura genera il file squid.redir, lo contrassegna come eseguibile ed esegue automaticamente un reload di squid.

Okay … ora provate a navigare utilizzando il vostro squid come proxy. Probabilmente non vi accorgerete di nessuna variazione nelle pagine web visitate. E’ molto probabile: infatti le regular expressions fornite come standard in questo redirector sono piuttosto obsolete e riferite in massima parte a procedure di advertising di server americani. Vi servirà un po’ di analisi del file access.log di squid per capire cosa dovete reindirizzare.

Un aiuto ? Bene … supponiamo di NON voler mai far scaricare ai browser dei nostri utenti di rete dei javascript che abbiamo individuato provenire sempre da http://www.qualcuno.com/scripts/pippo.js . Come fare ? Semplice :

1. Accedete alla console di comando del server squid
2. Entrate nella directory /usr/lib/squid
3. Con un editor di testo aprite il file di redir
4. In fondo al file aggiungete una nuova riga come questa :
   //www.qualcuno\.com/scripts/.*\.js [TAB] NULLJS
   ovviamente [TAB] significa il tasto TAB
5. Salvate il file e chiudete l’editor
6. Eseguite : make [Enter]
7. Squid viene ricaricato ed il reindirizzatore applicherà le sostitituzioni.

La lotta allo spam è una lotta senza quartiere. Tutti contro tutti. E accade spesso che aziende serie vedono la loro posta finire regolarmente nello spam degli utenti a cui cercano di inviare comunicazioni email. Perchè ?

E’ presto detto: le mail che inviano queste aziende vengono inviate con mezzi di dubbia affidabilità.

Cercerò di spiegarmi meglio : tutti sanno che uno dei modi per filtrare lo spam è analizzare il contenuto del messaggio e filtrarlo in base a specifiche parole chiave. Per esempio è facile capire che si vorrà segnare come spam qualsiasi messaggio che contenga la parola “Cialis”. Combinazioni complesse di queste parole chiave, organizzate in veri e propri dizionari, concorrono a formare quello che si chiama un filtro bayesiano. Ma questo è solo un modo per tenere pulita la posta. I server che ricevono la posta fanno molti altri controlli ancora prima di leggere il contenuto del messaggio e, sulla base dell’esito positivo o negativo, marcano immediatamente come spam (oppure rifiutano direttamente) il messaggio ancora prima di sapere cosa c’è scritto dentro.

Uno di questi controlli è quello che verifica la validità del SPF ovvero Sender Policy Framework: si tratta di una serie di informazioni che il proprietario del dominio mittente, dovrà inserire nel proprio DNS, per informare i server destinatari, quali sono gli indirizzi ip o i server di posta che sono autorizzati ad inviare posta originata dal dominio in questione.

Per esempio : il dominio taldeitali.com (che genera posta nella forma nome@taldeitali.com) avrà sicuramente configurato, nel proprio DNS, uno o più record MX per la ricezione della posta. Ma se vuole anche informare i propri corrispondenti (o meglio i server che ricevono la posta dei corrispondenti) su quali siano i server di posta che inviano la posta con quel dominio, dovrà dotarsi anche, sempre nel DNS, di un record TXT di tipo SPF. Ovvero dovrà iscrivere una istruzione che, grossomodo, dice : “quando ricevete della posta da @taldeitali.com, se la ricevete da questo IP, o da questo, o da questo allora l’abbiamo proprio inviata noi, altrimenti l’ha mandata qualcun altro facendo finta di essere noi, quindi quasi al 100% è spam.”

La direttiva SPF risolve efficacemente uno dei grossi problemi della posta elettronica, ovvero l’attendibilità del mittente. Infatti quando si riceve una mail, siamo in grado di vedere l’indirizzo del mittente, ma non possiamo essere sicuri che effettivamente la mail sia stata scritta dalla persona che è effettivamente titolare di quell’indirizzo email. Tanto è vero che, spesso, vi arriva spam originato addirittura dal vostro indirizzo di posta: e mandarsi lo spam da soli … sarebbe sciocco.

L’implementazione di un record SPF è, a mio modo di vedere, ormai doverosa … se non addirittura obbligatoria, proprio per evitare che la propria posta in uscita (legittima) non venga bloccata dal server del destinatario e marchiata a fuoco come SPAM. E questa necessità è tanto più forte quanto più le aziende (o meglio i loro domini) utilizzano una molteplicità di server per la gestione della posta: per esempio nel caso in cui un server viene dedicato alla ricezione ed un altro all’invio.

Cosa succede se non implemento questo tipo di direttiva ? E’ molto semplice : il server ricevente che effettua controlli sul record SPF tenterà di attribuirvene uno in automatico secondo questa regola: la mail che si sta cercando di recapitare viene consegnata da un server che ha lo stesso indirizzo IP di uno o più dei record MX del dominio ? Se si … Ok. Se no … l’indirizzo IP che sta cercando di recapitare la mail è uno di quelli indicati nel record A del dominio ? Se si … Ok. Se no … Soft-Fail ovvero la mail non passa.

A valle del controllo SPF verranno poi effettuati altri controlli come ad esempio la validità di un record PTR … ma di questo dirò un’altra volta.

Per informazioni dettagliate sul record SPF e per crearne uno … visita www.openspf.org.