[Linux-Biella] dubbio apocalittico: opqnbsd qmail spamassassin

[andrea_ferraris@libero.it]

Sull'argomento c'e` un post esemplare di Maurizio Tannoiser in 
it.comp.os.linux.sys. Lo consiglio vivamente, anzi, se ce l'ho sottomano 
lo attacco qui sotto:

Da:Maurizio - Tannoiser (tannoiser@despammed.com)
Oggetto:Re: Server Mail + DNS + PDC
View: Complete Thread (6 articoli)
Original Format
Newsgroups:it.comp.os.linux.sys
Data:2004-06-12 02:08:52 PST

On Fri, 11 Jun 2004 19:16:29 +0200, fosforo wrote:
>> Elimina spamassassin, che in un MTA puro, non serve a nulla potendo
>> utilizzare dnsbl, e riducendo inutilmente il carico.
> 
> Spiega Spiega, come funziona dnsbl, è un pacchetto, una configurazione?
> Ritieni spamassain inutile? dnsbl è una soluzione migliore?

Nell'ordine.

a. l'uso delle dnsbl/rbl e` una configurazione in $TUOMTA, che permette,
mediante liste distribuite, di filtrare a monte della comunicazione
smtp, la fonte dello spammer.

I manutentori di queste liste di "ip" noti, sono i piu` vari e con scopi
diversi. Si va da liste di macchine di cui e` nota la
misconfigurazione/compromissione (openrelay, openproxy...), a liste di
ip da cui proviene spam confermato, a liste di boicottaggio di vario
genere.

Ovviamente la "tara" dipende da troppi fattori per cui esista una
configurazione "unica". Uno di questi fattori, e` a chi devi fornire il
servizio (clienti, interni, ecc.).

b. ritengo (ma non solo io), l'uso delle liste di blocco ampiamente piu`
utile ed efficente, di "content filter" alla spamassassin, per diversi
motivi:

i. traffico. La comunicazione smtp viene interrotta sulla base dell'ip
d'origine.

ii. contesto. Io non voglio spam da te signor spammer. I content filter,
accettano lo spam, e successivamente, esso viene analizzato, quindi
(comportamento a piacere).

iii. Su mta ad alto traffico, sciupa molte risorse un content filter.

iv. falsi positivi. Se un mta legale finisce in una BL, si verificano
due cose: tu gestore, hai una traccia nei log, ma sopratutto, io
"inviante", ho un messaggio di errore di ritorno che mi dice perche` la
mia mail non e` stata consegnata. Questo permette un agevole tracking
dei problemi, e una facile risoluzione (whitelist).

Con un content filter, l'inviante non riceve errori. La comunicazione,
che avviene "prima", giunge a termine correttamente. _POI_ viene
analizzata la mail. A questo punto, qualunque intervento di "avviso"
sarebbe peggio, perche` non hai elementi sufficientemente corretti per
sapere chi ha mandato la mail (il campo from non e` attendibile).

Se imposti spamassassin per cancellare i messaggi, un messaggio
erroneamente segnato come spam e` perso, e _nessuno_ si accorge di
questo.

Quindi, l'unico uso concreto di spamassassin e` il tagging.

In tutto questo, su un MTA che viene "contattato", spamassassin non solo
e` poco utile, ma arriva ad essere quasi dannoso.

In taluni casi, invece e` una soluzione praticabile, nel senso che
"piuttosto che niente e` meglio piuttosto". Se la posta la scarichi da
un ISP, mediante fetchmail (per dire), e chiaro che non puoi agire a
livello smtp (la posta e` gia` stata accettata correttamente dal tuo
ISP). Quindi un meccanismo di filtraggio, si rende necessario. Ma anche
qui, prima di buttare a dev/null i messaggi che spamassassin marca come
spam, ci penserei.

Puo` bastare? :)

> A proposito, esiste un antivirus free da usare con amavis e che abbia
> gli aggiornamenti automatizzati?

clamav. Chi lo usa ne dice un gran bene.


-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG http://erlug.linux.it
-------------------------------------------------------------------------------
Security-wise, NT is a server with a "Kick me" sign taped to it.