Tutti sanno cosa sia un messaggio e-mail, come si faccia a mandarlo e come si possa ricevere. Eppure solo una piccola parte degli utenti internet conosce davvero cosa succede “dietro le quinte” quando si invia o si riceve posta elettronica. Del resto i moderni client di posta elettronica (Thunderbird, Outlook Express, Outlook, Eudora, The Bat! ecc..) svolgono silenziosamente il “vero” lavoro di comunicazione e trasmissione dei nostri messaggi: tutto quello che ci è richiesto è di impostare correttamente alcuni parametri iniziali (server POP/IMAP, server SMTP ecc) e poi siamo pronti ad inserire un indirizzo email, compilare un oggetto, digitare un po’ di testo nel corpo del messaggio e … voilà, dopo un clic su Invia il messaggio viene recapitato.

Ma cosa avviene in realtà ?

Per semplificare possiamo tranquillamente equiparare il servizio di posta-elettronica ad un normale servizio di posta cartacea (le normali buste che mettiamo nella buca delle lettere): la logica è la stessa anche se, ovviamente, la tecnica è molto differente. Con la normale posta cartacea (detta anche posta di superficie) mettiamo il nostro foglio dentro una busta, scriviamo sulla busta l’indirizzo del destinatario ed anche il nostro indirizzo (mittente) in modo che, ove non sia possibile raggiungere il destinatario, la busta ci venga restituita, ed infine mettiamo la busta in una buca per le lettere o la portiamo direttamente all’ufficio postale per essere spedita. Supponendo di mandare una lettera da Milano a Roma, il servizio postale di Milano manderà la nostra busta al centro postale di Roma dove un postino provvederà a portarla nella cassetta della posta del destinatario. Se per qualche motivo il destinatario è stato indicato con un indirizzo sbagliato, o ha cambiato residenza, il postino riporterà la busta al centro di Roma che la rispedirà a Milano per essere recapitata al mittente.

Tutto chiaro no ? Bene: con la posta elettronica la logica è esattamente la stessa.

Quando siamo pronti ad inviare il nostro messaggio di posta elettronica succede questo: il nostro client (per esempio Outlook Express) prepara una “busta elettronica” (envelope) nella quale indica i dati del destinatario e del mittente (gli indirizzi email di chi deve ricevere il messaggio e di chi lo manda), ci inserisce il testo che abbiamo scritto e gli eventuali allegati (foto, documenti ecc) e consegna il tutto all’ufficio postale che è incaricato della consegna ovvero il server SMTP che, generalmente, ci è stato indicato dal nostro provider di connettività o dal gestore che mantiene le nostre caselle postali. A questo punto il server SMTP (che possiamo assimilare al centro postale di Milano) trasmette il messaggio al server SMTP che è autorizzato a ricevere le email per il destinatario che abbiamo indicato (come fosse ad esempio il centro postale di Roma): quest’ultimo verifica se il destinatario esiste nei propri archivi (ovvero se esiste una casella postale con quell’indirizzo) e, in caso affermativo, deposita il messaggio nell’opportuna casella postale, mentre in caso negativo, risponde al server che gli sta inoltrando il messaggio chiedendo di informare il mittente che il destinatario non è raggiungibile.

Il processo che ho descritto è volutamente semplificato (trascuro in questo post quelle che possono essere le implicazioni di passaggi in uffici postali intermedi – i cosiddetti relay servers) ma rispecchia fedelmente quello che avviene in realtà.

Ma cosa è un server SMTP ? O meglio … cosa è SMTP ? Come la stragrande maggioranza delle sigle che si incontrano nel mondo dei computer, SMTP è l’acronimo inglese di Simple Mail Transfer Protocol ovvero il protocollo per la trasmissione internet di messaggi mail. I server che implementano questo protocollo si chiamano MTA (Mail Transfer Agent ovvero Agenti di Trasporto e Consegna delle mail) e sono quei server che dobbiamo indicare nella configurazione del nostro client di posta elettronica alla voce server SMTP.

Il protocollo SMTP è un protocollo relativamente semplice, fondamentalmente testuale in codifica ASCII (quindi “leggibile” da un umano), apparso agli inizi degli anni 80 e da allora rimasto sostanzialmente immutato. La sua semplicità è sicuramente punto di forza per la facilità di implementazione e per l’indubbia efficacia, ma è anche gravata da un notevole peso: la mancanza di sicurezza.

Il maggiore punto debole di SMTP sta nel fatto che non è in grado di verificare l’autenticità del mittente. Esattamente come un uomo può inviare una busta affrancata indicando come mittente un nome/indirizzo di fantasia (che può esistere o meno), così nelle email il protocollo SMTP non offre nessuna garanzia che il mittente di un messaggio sia effettivamente quello indicato. Iniziate a capire vero ? Questa mancanza di autenticazione del mittente apre la stura ad una serie di problemi : in primo luogo lo SPAM ed in secondo luogo l’attendibilità della fonte da cui arrivano le informazioni che leggiamo nel messaggio.

Ed ecco che appare chiara la risposta ad alcune domande molto ricorrenti : “Come mai mi arriva tutto questo SPAM ? Come fanno a sapere il mio indirizzo email ? Come mai a volte lo SPAM arriva dal mio stesso indirizzo ?” Semplicemente perchè il servizio postale elettronico non si cura di verificare che chi ha inviato un tale messaggio abbia indicato in modo corretto il mittente e sia veramente lui: l’unica cosa di cui si occupa l’MTA è quella di tentare di recapitare il messaggio al destinatario indicato e, in caso di fallimento, di ritornare al mittente un avviso (bounce). E qui si apre un altro problema : quello che si chiama il backscattering. Un esempio può aiutare più di mille parole: Mario (il nostro buontempone) invia una busta a Giovanni indicando come mittente Gianluca. Se il postino non riesce a consegnare la busta a Giovanni, cosa farà ? Semplice ritornerà la busta al mittente indicato sulla busta stessa ovvero a Gianluca. Ed ecco che Gianluca si vede, incolpevolmente, coinvolto in un giro di SPAM. Già, perchè gli spammers hanno capito che i “bounce-messages” (ovvero i messaggi di ritorno per mancata consegna) godono di una sorta di “privilegio” nella consegna ed è più facile che eludano i sistemi antispam. Così, volutamente, confezionano dei messaggi destinati ad indirizzi inesistenti indicando come “mittente” il loro vero obiettivo: in questo modo il bersaglio dello SPAM riceverà il messaggio non desiderato sottoforma di errore di recapito, spesso non capacitandosi del perchè si sia verificata questa situazione (“Ma io non ho mandato mai questo messaggio a questo indirizzo !!”).

Ma mentre è piuttosto raro trovare “buontemponi” che si divertano ad imbucare lettere fasulle mandate ad indirizzi a caso (e da indirizzi fasulli) prevalentemente per motivi di costo (il francobollo), l’economicità e la velocità (oltre all’indubbio anonimato) offerte dalla tecnica di trasmissione email valgono oro per gli SPAMMERS. Per un computer generare milioni di indirizzi casuali è un gioco da ragazzi: che importa poi se su qualche milione di email inviate solo poche migliaia raggiungono veramente dei destinatari reali ? Che importa se i server SMTP cercano di inviare ricevute di mancato recapito ad indirizzi inesistenti ? Gli SPAMMER raggiungono comunque i loro obiettivi: che siano economici (come le pubblicità dei prodotti per la virilità o i tentativi di rubarvi le credenziali per l’accesso al vostro conto corrente bancario – phishing) o più sofisticati (come per esempio quello di recapitare sul vostro computer tramite l’email dei programmi malevoli) anche se i tassi di ritorno sono bassi, è talmente alta la quantità dei messaggi inviati che i valori assoluti sono comunque rilevanti. Basti pensare che numerosi studi attestanto mediamente tra il 90% ed il 97% la percentuale dei messaggi NON RICHIESTI inviati quotidianamente.

Ma come ci si può proteggere da tutto questo ? E’ molto difficile rispondere. Una cosa è certa : non è possibile combattere e prevenire lo SPAM basandosi solo sulle caratteristiche di SMTP. E’ necessario chiamare alle armi altri strumenti, altri protocolli, altri software per cercare almeno di ridurre il fenomeno.

Ma è anche importante distinguere due campi di battaglia molto diversi: la protezione personale contro lo spam ovvero il micro campo di battaglia nel quale io stesso cerco di difendere il mio fortino costituito dalla mia casella postale e, su un piano totalmente diverso, la protezione globale che ha come obiettivo quello di ridurre il traffico email SPAM (che impegna banda, risorse di memoria e spazio su centinaia di migliaia di server) per poter garantire servizi internet più efficienti e veloci.

Le tecniche possono essere simili per entrambi gli ambiti, ma vanno applicate con cure ed accortezze molto diverse: se per esempio a livello di protezione personale decido che tutte le email che contengono la parola “Viagra” vadano automaticamente cestinate o messe nella Posta Indesiderata, il gestore di un server di posta per diversi domini non potrà permettersi lo stesso “lusso” perchè potrebbe esserci il caso in cui uno dei suoi clienti sia un medico e che come tale vuole ricevere informazioni mediche sul famoso prodotto della Pfeizer. Anche l’implementazione di tecniche antispam a livello di server aziendali non deve essere presa alla leggera: i contatti via email sono un canale essenziale di comunicazione con la clientela e perdere messaggi magari importanti per errate impostazioni dei filtri può essere un danno per l’azienda.

Insomma la guerra allo SPAM è, per il momento, allo stadio di battaglia persa. Con questo non intendo dire che non si possa validamente riuscire a ridurre lo SPAM, anzi è senz’altro possibile: il problema è che il costo (sia in termini di investimento software, che in termini di tempo) è notevole e supera di gran lunga il poco impegno richiesto a chi vive dello SPAM sfruttando, purtroppo, le debolezze insite in un protocollo nato quasi 30 anni or sono.

Nella mia carriera ho testato diverse soluzioni server per cercare, almeno, di ridurre sensibilmente il numero di email non richieste che quotidianamente intasano le nostre caselle email e quelle dei nostri clienti. E devo dire che tra tutte, molte delle quali a pagamento – anche molto care -, nessuna arriva alla efficacia ed alla flessibilità offerta da ASSP (Anti Spam SMTP Proxy) : una soluzione completamente open, gratuita, multipiattaforma e dalle non eccessive richieste di risorse. Il “core” dell’intera applicazione è un unico file Perl (1Mb in totale) che sfrutta diversi moduli standard dei repository Perl.

Non si tratta certamente, come nella più pura filosofia FOSS, di una applicazione Setup->Config->Run: per essere implementata a dovere richiede una discreta conoscenza di base, la capacità di sapersi barcamenare tra versioni di Perl diverse (o ActivePerl per chi ha intenzione di utilizzarlo su un server Windows), una buona conoscenza delle regole RFC per il protocollo SMTP (molte impostazioni fanno esplicito riferimento a regole RFC per la loro comprensione), una buona dimestichezza con le Regular Expressions e, infine una forte pianificazione di come gestire il flusso delle email in ingresso ed in uscita.

A parte tutto questo (che non è poco – la conoscenza di per se è un valore conquistato al costo di tante ore di studio e di prove), questo software apparentemente modesto racchiude gli strumenti di controllo contro lo SPAM più sofisticati e completi che abbia mai visto: tra tutti il classico filtro bayesiano è proprio l’ultima ruota del carro. Ed è giusto che sia così. Classificare lo SPAM in base al contenuto dei messaggi è molto poco efficiente: prima di tutto perchè il messaggio (o meglio dire le migliaia di messaggi) sono comunque stati ricevuti (al costo della vostra banda) ed in secondo luogo perchè l’efficacia dei filtri basati su parole chiave è sempre più spesso messa in crisi dalle tecniche degli spammatori che inseriscono volutamente nei loro messaggi combinazioni di parole che, a puro titolo di esempio, nulla hanno a che vedere con il Viagra, ma hanno il preciso intento di far diminuire lo score del messaggio per farlo apparire legittimo.

Ecco allora che con ASSP potrete facilmente rafforzare la vostra barriera di controllo ampliando lo spettro dei test più verso il mittente che verso il contenuto del messaggio. Controlli sulla presenza dell’IP mittente nelle più utilizzate blacklist, verifica dell'”insistenza” con cui un determinato IP cerca di connettersi, ban degli IP che tentano di consegnare posta a troppi indirizzi inesistenti, verifica delle forme corrette negli HELO, controllo sulla corretta sequenza degli header, degli ID di messaggio, verifiche dei record MX/A nei domini mittenti ecc. Il tutto sintetizzato in uno schema di punteggi a soglia, superata la quale, le connessioni da determinate sorgenti di SPAM vengono subito bloccate prima ancora di ricevere i primi dati. Ovviamente è sempre possibile integrare i controlli con whitelist ad apprendimento automatico e, infine, effettuare controlli bayesiani sul “corpus”.

Con impostazioni discretamente aggressive, su un server dedicato a questo scopo, dei circa 95mila tentativi di consegna di posta al giorno, ne blocchiamo sul nascere oltre il 94%. I benefici in termini di banda risparmiata sono notevoli: non solo limitiamo i consumi in ingresso, ma riduciamo anche quelli in uscita in quanto i clienti che scaricano la posta in POP si trovano un numero molto minore di dati da scaricare.

Ci si accorge presto tuttavia che non sono tutte rose e fiori : purtroppo anche moltissime email legittime non riescono a superare i ferrei controlli che il rispetto delle regole RFC imporrebbero. Improvvisati sistemisti configurano server di posta interni per piccole lan locali dimenticandosi di configurare in modo opportuno i DNS, di richiedere l’iscrizione di un corretto PTR, oppure abusano delle loro connessioni per mandare in giro newsletter, o lasciano i relay aperti (cosa che immediatamente li fa entrare nelle blacklist tipo spamhaus), o, ancora, utilizzano word come editor html dei messaggi per il loro Outlook (il che genera un tale casino nel testo del messaggio che è impossibile classificarlo come legittimo per parole chiave). E mille altri casi.

Alto quindi il rischio di perdere email importanti, inviate da emeriti ignoranti: anche qui, tuttavia, ASSP aiuta nella eliminazione di questo pericolo. L’iscrizione di determinati indirizzi (o interi domini) negli elenchi degli SPAMLOVERS permette di far comunque arrivare (opzionalmente taggati) tutti i messaggi a loro destinati, o, in alternativa, è possibile far generare ad ASSP un rapporto dettagliato delle email bloccate in modo che il proprietario della casella “protetta” possa richiedere l’iscrizione in white-list dei corrispondenti che gli interessano. In alcuni casi è anche possibile chiedere che venga forzato il recapito del messaggio bloccato.

Insomma, davvero un coltellino svizzero, che permette un fine-tuning delle vostre esigenze antispam a livello di server di posta.

L’ultima release stabile è la 1.5.1 ma da quello che vedo sul loro sito è in cantiere una beta della 2.0 che promette nuove caratteristiche tra cui il multithreading.

ASSP Rocks.