Newsgroup: it.news.net-abuse
Titolo: DNSBL vs spamassassin

Vorrei un parere sulla seguente questione. 
Noi siamo un istituto di ricerca e la nostra configurazione antispam 
(prevalentemente a suo tempo istigata da me) si basa su una sequenza di 
DNSBL chiamate da sendmail 8.13.1 (come OS ormai siamo praticamente 
tutti sotto SuSE).
A questo poi chi vuole aggiunge altre cose, in genere nulla, qualcuno 
qualche filtro a livello del cliente con cui legge la posta, io ho un 
corposo set di regole anche content-based basate su procmail.
Il tasso di traffico e' dell'ordine di 500 mail "tentativamente 
legittimi" e 500 spam (rigettati dalle DNSBL) al giorno (il rapporto 1:1 
e' indicativo, un giorno puo' essere 700:500 e un altro 500:700). 
I mail "tentativamente legittimi" probabilmente includono una ulteriore 
buona frazione di spam, a giudicare dalla statistica dei dominii da cui 
provengono. Il numero di falsi positivi autentici e' molto basso (sara' 
capitato un paio di volte in qualche anno che domini accademici con cui 
corrispondiamo finissero blacklistati). C'e' stato qualche caso di 
piccole ditte con cui abbiamo una corrispondenza legittima che si 
appoggiavano a provider blacklistati (e in questo caso abbiamo usato lo 
hack di aggiungere un indirizzo secondario col + aggiunto all'indirizzo 
del nostro utente per whitelistarlo in modo selettivo).
Ci sono ovviamente casi di mail "privati" inviati da persone che si 
appoggiano ai grossi provider telefonici italiani che finiscono ogni 
tanto blacklistati, ma finora, non trattandosi di mail "di lavoro" la 
risposta (caldeggiata anche dal nostro system manager che non ha mai 
ritenuto di whitelistare interi dominii commerciali) e' stata : o di 
usare lo hack di cui sopra, oppure di farsi mandare la posta su un 
mailbox privato altrove.
Io personalmente sono soddisfatto del mio arrangiamento personale (con i 
miei filtri extra avro 2-5 spam al giorno che finiscono filtrati, il che 
e' molto meno di quanto passa sul mio account privato alla Rete Civica 
Milanese che dice di usare un antispam commerciale).
Ci sono state pero' osservazioni di qualche utente che da una parte 
riceve un po' piu' di spam (perche' non ha filtri suoi) e/o che ha un 
tot di "amici e conoscenti" che vengono blacklistati, e dall'altra dei 
suggerimenti (a livello di ente, ma non accompagnati da una chiara 
direttiva e da una configurazione standard) a passare a una 
configurazione basata su spamassassin. 
Io ho dato una rapida occhiata alla documentazione (che non pare 
chiarissima), e mi pare di capire che, mentre il meccanismo dei filtri 
bayesiani autoapprendenti dovrebbe aumentare l'efficienza della parte 
content-based, la configurazione standard sia una che fa "tagging" e non 
che respinge i mail a livello di connessione sendmail. E' corretto ?
Non vorrei quindi che da una parte poi gli utenti medi si lamentassero 
di dover filtrare spam taggato in eccesso a quello che ora passa le
blacklist, e che utenti come me dovessero riscrivere pesantemente le 
proprie regole di filtraggio procmail.
Vorrei quindi un parere sull'uso di una configurazione basata su 
spamassassin rispetto a una basata sulle DNSBL in termini di efficienza 
e facilita' di configurazione.
-- 
----------------------------------------------------------------------
nos...@mi.iasf.cnr.it
 is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

che respinge i mail a livello di connessione sendmail. E' corretto ?
Esatto. Proprio per questo motivo ritengo che sarebbe un grosso passo
indietro, con i volumi di spam attuali molti utenti finirebbero per
cancellare i falsi positivi di SA insieme a tutto il resto (e i mittenti
non avrebbero alcun feedback di questo!).
-- 
ciao, |
Marco |  The Italian Usenet Cabal, Abuse Department (TINC)
"It's about damn time that all of us who actually give a damn about Usenet
stand up and tell the people who don't to fuck off and die." -- Russ Allbery


Io utilizzo spamassassin accoppiato con un filtro milter, il filtro milter 
analizza la mail richiamando la libreria spamassassin la quale ritorna al 
filtro il punteggio di spam. Sulla base di quello che ha deciso l'utente a 
livello di configurazione di mailbox, il filtro tagga la mail e segnala a 
sendmail di continuare a processare la mail (SMFI_CONTINUE) oppure fare un 
Reject/Discard (SMFI_DISCARD, SMFI_REJECT).
In questo modo lo spam non arriva neppure alla casella se l'utente ha deciso 
di non ricevere spam, quindi niente pasticci post consengna con procmail 
ecc.
Spam assassin è gestito system wide, non a livello di utente, l'utente non 
esiste nemmeno, non vi è corrispondenza casella di mail-unix account.
Fare reject sulla base di quello che dice una DNSBL è sbaglito. Nessuna 
DNSBL è degna di tanta fiducia. L'unica manera per ridurre i falsi positivi 
è basarsi su check multipli Rete-Bayes-regole statiche locali su header e 
body.

 body.
Mi piace vedere gente cosě piena di certezze... :-)
La questione č cmq stata abbondantemente dibattuta pressochč ovunque si
parli di spam (mi rivolgo ovviamente all'OP).
Volendo essere brevi, possiamo dire che:
- poichč la presenza in DNSBL č il *sintomo* di un problema e non il
problema in sč. Il reject DNSBL-based funge quindi da meccanismo di
allarme in direzione del mittente, il che porta sovente alla soluzione
di problemi che altrimenti restan lě. Ovviamente il gioco vale la
candela fintantochč le DNSBL sono a basso tasso di falsi positivi
(praticamente tutte le liste di proxy/zombie)
- l'approccio basato sui soli dati di envelope (o, al piů, di check su
header), di cui cmq le DNSBL sono solo una parte, č pressochč vitale per
qualsiasi soluzione debba gestire un carico appena decente.
L'alternativa č la completa accettazione e "categorizzazione" del traffico.
- l'approccio pre-queue, se applicato in maniera aggressiva, richiede
maggiore confidenza con il tema di quello post-queue, e molto lavoro in
piů (in manutenzione, sviluppo, ricerca e -a volte- coding).
- come per molte cose, probabilmente "in medio stat virtus", e vale la
pena di prendere in considerazione un approccio misto, con un primo
strato di rejection seguito da un secondo di categorizzazione.
Consiglio cmq, a priori, una lettura del paper di Furio, che dovrebbe
aiutare a capire per quali tipologie di spam conviene un approccio
DNSBL-based (sorgenti pure) e dove invece conviene un approccio su
content-filter (sorgenti miste):
http://www.fisica.uniud.it/~ercolessi/email/blocco.pdf
Bye.


mmmm, ci dò un'occhiata.

 che respinge i mail a livello di connessione sendmail. E' corretto ?
Si, è esatto, ed il discorso sarebbe abbastanza lungo da portare
avanti su un newsgroup, il principio di filtraggio bayesiano si basa
sull'autoapprendimento del filtro che dovrebbe essere istruito in
modo da distinguere tra quello che è "spam" e quello che fa parte
del normale traffico email, ora, se si parla di un ambito "ristretto" è
abbastanza facile definire il concetto di "spam/nonspam" dato che
il traffico di email regolari è abbastanza omogeneo, è diverso invece
il discorso di un mailserver che serve un'utenza "disomogenea", in
questo caso un vero filtraggio bayesiano è pressochè improponibile
per cui, onde evitare "falsi positivi" si ricorre al tagging, che, se da un
lato permette all'utente finale di stabilire se una email è spam o meno,
dall'altro causa un flusso di traffico inutile, al proposito esistono però
alcune soluzioni che potrebbero essere prese in considerazione come
ad esempio 
http://assp.sourceforge.net
 questo filtro, oltre ad implementare
vari metodi di controllo (DNSBL, scansione AV, SPF ed altro ancora)
ha il vantaggio di generare degli errori a livello SMTP per cui il mittente,
nel caso in cui il messaggio venisse rifiutato, riceverebbe comunque una
email relativa all'errore, oltre a questo, ASSP implementa anche un
meccanismo di whitelisting automatico, in pratica se un utente che viene
considerato "affidabile" invia un messaggio email, il destinatario di tale
messaggio verrà automaticamente posto in whitelist per un periodo di
tempo configurabile (potremmo paragonare la cosa al TTL del DNS)
questo evita o quantomeno aiuta ad evitare i falsi positivi e permette
di evitare che le email valide vengano erroneamente filtrate
Ciao

 Ho stabilito il limite massimo a 100000 messaggi di posta al giorno, 
E' cmq un valore cui associo l'etichetta di "poco traffico".
Assicuro [ ma non lo dico io, lo dicono gli eminenti autori del SW del
caso ;-) ] che è una soluzione che tende a scalare piuttosto male...

 ha scritto nel messaggio 
news:dr2v71$ckp$1...@half.spin.it...

Spamassassin utilizza molta ram, questo è vero. A questo aggiungici che 
l'implementazione di spamd prima della 3.1.0 non era idilliaca, la 3.1.0 è 
uscita con una versione di spamd decente, le precedenti se avevi bisogno di 
25 connessioni simultanee ti forkavano 25 processi spamd, per di più c'erano 
memory leak, ora risolti riclando i processi ogni tot query, come apache per 
intenderci.
Quello che più preoccupa è che ci mette 5 secondi medi per analizzare i 
messaggi pertanto se ragioni a server di mail centralizzato anziche 
soluzione distribuita, oltre più di tanto non puoi andare, devi disabilitare 
diversi check, perlopiù di tipo Net che sono quelli che rallentano di più.
Quello che dà valore a spamassassin sono i check combinati, in questo modo 
riduci quasi a zero i falsi positivi, avere qualche cosa di più snello 
significa meno controlli quindi meno accuratezza.