Newsgroup: it.news.net-abuse
Titolo: Info su dbl.spamhaus.org

Ciao,
domanda su 
dbl.spamhaus.org
, rispetto ad es. a SURBL, la differenza
principale sta nella rapidità di aggiornamento, o ci sono altre
differenze sostanziali?
grazie,
Gabriele

 differenze sostanziali?
Parecchie (e sulla "rapidit� di aggiornamento" ci sarebbe poi da aprire
un thread piuttosto articolato...).
SURBL esiste per il solo lookup di URI.
DBL permette il lookup di URI, ma anche di zone inverse, domini
mittenti, HELO string (per gli utenti di postfix si veda
http://bofhskull.wordpress.com/2010/03/01/sempre-su-dbl/
).
SURBL lista anche IP qualora siano direttamente utilizzati un URI.
DBL non lista alcun IP ( anzi: a dire il vero li lista tutti :-D [1]) e
si aspetta che le query si IP contenute in URI vadano dirette a SBL.
Le differenze sono poi la ragione per la quale il supporto a DBL avverr�
solo con la nuova versione di Spamassassin, poich� il codice usato da SA
per il lookup su SURBL e URIBL non � adatto a DBL.
[1] Perch� � prevedibile che la gran massa degli utenti pirla partiranno
immediatamente configurando DBL sull'MTA come fosse l'ennesima
XBL/SBL/PBL/ecc, subissandola di query che non c'entrano una fava. Che
infatti � esattamente quel che sta accadendo...
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 per il lookup su SURBL e URIBL non � adatto a DBL.
Ah, e a questo riguardo: se non avete SW che supporti espressamente DBL,
per ora *lasciate perdere* e aspettate l'aggiornamento che lo introduce
a meno che non sappiate esattamente cosa state facendo.



[cut]
Grazie mille :)
Un esempio di utilità nella verifica dell'HELO usando DBL? giusto per
capire rispetto ad una verifica classica riguardante solo la sintassi
o HELO fantasiosi.
Gabriele

 o HELO fantasiosi.
Niente HELO fantasiosi (almeno per ora) in DBL.
Una parola su tutte: snowshoe.
Dato che � gente che invia da domini propri (ma usa-e-getta), da
mailserver veri posti in datacenter veri e con zona inversa
meticolosamente impostata, se non li blocchi sull'IP devi avere qualche
altro fattore su cui bloccarli.
HELO string, zona inversa e dominio mittente (tutti relativi al dominio
dello spammer, appunto) sono la prima linea.


 Ah, e a questo riguardo: se non avete SW che supporti espressamente DBL
URIBL_DBL io me lo ritrovo già da qualche tempo, con gli aggiornamenti
da squeeze...

 dello spammer, appunto) sono la prima linea.
In pratica, come la stai usando, al momento?
reject_rhsbl* ?


Yep:
reject_rhsbl_helo 
dbl.spamhaus.org
=127.0.1.2
reject_rhsbl_client 
dbl.spamhaus.org
=127.0.1.2
reject_rhsbl_sender 
dbl.spamhaus.org
=127.0.1.2


 reject_rhsbl_sender 
dbl.spamhaus.org
=127.0.1.2
Ma in pratica DBL si può usare come lookup
di url in maniera tale e quale a SURBL ed al
contempo verificare che un tale url (o dominio)
non sia usato anche come HELO o sender?
In pratica, posso tranquillamente filtrare tutti
e tre i dati usando DBL avendo cura di rigettare
solo i record 127.0.1.2 ?

 solo i record 127.0.1.2 ?
Corretto.
In realtà la cosa da fare sarebbe proprio *non* inviare query per IP a
DBL, al di là di verificarne poi il return code (che comunque s'ha da
fare, onde evitare sorprese).
Per questo è opportuno che il codice che effettua la query sia specifico
per DBL...


 per DBL...
Tipo il mio per exim?
Son troppo avanti....

 
http://bofhskull.wordpress.com/2010/03/01/sempre-su-dbl/
).
Perdona la mia ignoranza, purtroppo per le tante cose da fare non riesco 
a tenermi aggiornato sulle ultime novita' in fatto di soluzione ai 
problemi di spam e simili.
Tempo fa avevo installato postfix con amavisd-new + clamav e impostato
reject_rbl_client 
zen.spamhaus.org
,
reject_rbl_client 
bl.spamcop.net
,
reject_rbl_client 
safe.dnsbl.sorbs.net
nel main,cf di postfix, inoltre uso postgrey.
Lo spam e' ridotto ma non eliminato.
Visto che hai citato postifix sono andato sul sito da te indicato e ho 
letto che parli di milter.
Ho visto che tra i pacchetti debian oltre ad amavisd-new c'e' anche 
amavisd-new-milter.
Qual'e' la differenza tra i due.

 Qual'e' la differenza tra i due.
Il motore � sostanzialmente lo stesso, cambia il modo in cui viene
richiamato.
amavisd-new agisce in post-queue: postfix *accetta* la mail, poi la
passa ad amavis, che fa le sue smandruppe e la ripassa a postfix.
Va bene se vuoi taggare le mail, o se vuoi metterle in quarantena, ma
non puoi usarlo per rigettarle, dato che le hai gi� accettate: se le
rigetti a quel punto, infatti, generi un bounce che -nel caso di gran
parte dello spam- va a un indirizzo che non c'entra nulla con la mail
che stai ricevendo. Backscatter, di nuovo.
I milter invece vengono richiamati durante la fase end-of-data (pi� o
meno) quindi puoi analizzarne il contenuto e decidere di rigettarla
senza rischio di backscatter.



Sto usando amavis come, diciamo, scusa per il gergo non tecnico, ponte 
tra postfix e clamav, le mail scartate da clamav vengono rigettate.
Per i filtri antispam uso le reject che ho indicato oltre a postgrey.

 tra postfix e clamav, le mail scartate da clamav vengono rigettate.
Questo � male, se stai usando amavis in modalit� "classica", per il
discorso backscatter suddetto.
Se poi usi amavis solo per clamav, puoi essere decisamente interessato a
sostituire il tutto con clamav-milter, che rende amavis (milter o no) di
fatto inutile...
A quel punto amavis-new-milter ti serve solamente se vuoi adoperare
ulteriori antivirus (o altro genere di marchingegno) che non supporti
l'interfaccia milter di suo...


 
Ho visto che tra i pacchetti debian lenny c'e' un amavisd-new-milter, 
vedo se trovo un po di doc e spero, nel caso, che sostituendolo con 
l'attuale amavisd-new non mi provochi un disservizio.

 le mail scartate da clamav vengono rigettate.
Insomma, sei un backscatterer.


Perche'?
La mail viene rigettata nel senso che non viene rimandata indietro, 
viene scartata.

 viene scartata.
Allora non viene rigettata. Viene droppata (o messa in quarantena, se ne
mantieni copia).
In ogni caso, fossi in te valuterei l'adozione di clamav-milter (o di
milter-clamc :-P) comunque...


 viene scartata.
E allora è discarded, non rejected. ;-)

 
Si infatti, sto leggendo qualcosa in rete.
Sembrerebbe che da quando postfix supporta il milter di amavis non ce ne 
sia piu' bisogno.


Si ma non viene rimandata indietro se ho capito cosa significa 
backscattered.

 introduce a meno che non sappiate esattamente cosa state facendo.
Con ASSP v2 funge perfettamente; l'ho messa in test e non ho avuto
alcun problema anzi, giudicando dai rejects sembra anche piuttosto
efficiente :)

 efficiente :)
Sotto che altri ruleset l'hai messa?
a me non ï¿œ che stia bloccando molto.

 a me non ï¿œ che stia bloccando molto.
La sto usando banalmente come URIBL

 La sto usando banalmente come URIBL
con questo
http://sourceforge.net/projects/assp/files/ASSP%20V2%20multithreading/
(la v2 ora ï¿œ ufficiale, ï¿œ uscita dalla beta)

 La sto usando banalmente come URIBL
Non mi hai capito.
Che altri filtri hai prima di arrivare a
questa URIBL ?
Altre URIBL? 45 RBL?
Da me ï¿œ la 6 o 7 BL, sotto zend, spamcop, ed altre,
nonchï¿œ la terza URIBL e non filtra molto.

 nonchï¿œ la terza URIBL e non filtra molto.
beh... nel mio caso tutto l'ambaradan funziona in un
modo un filino diverso :) in qualsiasi caso quando ho
scritto "buona efficienza" intendevo in rapporto alle
altre due, in generale non ï¿œ che arrivino moltissime
emails al check URIBL dato che molto spesso sono
rigettate prima

 In ogni caso, fossi in te valuterei l'adozione di clamav-milter (o di
Scusa ma esiste della documentazione esaustiva per configurare 
clamav-milter con postfix?
Ho installa clamav-milter da volatile.debian ma postfix non ne vuole 
sapere di collegarsi al socket:
connect to Milter service unix:/var/run/clamav/clamav-milter.ctl: No 
such file or directory

 such file or directory
Come per qualsiasi daemon che debba comunicare con postfix via domain
socket, questo va configurato per essere in ascolto all'interno del
chroot di postfix (/var/spool/postfix).
Ovviamente, postfix deve anche essere in possesso dei relativi permessi
di lettura e scrittura per lo stesso...


 chroot di postfix (/var/spool/postfix).
In effetti questo e' indicato nel README.Debian, sono rimasto titubante 
poiche' in una precedente versione di clamav-milter, in 
/etc/default/clamav-milter.conf, c'erano delle opzioni da settare per 
l'uso con postfix che poi son sparite con l'upgrade, percio' ho pensato 
che si dovesse intervenire solo /etc/clamav/clamav-milter.conf.

 di lettura e scrittura per lo stesso...
/var/spool/postfix# ls -l
drwxrwsr-x  2 clamav  postfix  4096  8 mar 14:50 clamav
ls -l clamav
srwxrwxr-x 1 clamav postfix 0  8 mar 14:50 clamav-milter.ctl
vi /etc/default/clamav-milter
USE_POSTIX='yes'
vi /etc/clamav/clamav-milter.conf
MilterSocket /var/spool/postfix/clamav/clamav-milter.ctl
vi /etc/postfix/
main.cf
smtpd_milters = unix:/var/spool/postfix/clamav/clamav-milter.ctl
milter_protocol = 2
Ciononostante:
warning: connect to Milter service 
unix:/var/spool/postfix/clamav/clamav-milter.ctl: No such file or directory

 directory
Do you know "chroot"? :-P
Prova
smtpd_milters = unix:/clamav/clamav-milter.ctl

whiplash ha scritto:

:-( mortificato, scusa hai ragione, vado a riposare perche' sono fuso :-(

> per DBL...
GC> Tipo il mio per exim?
GC> Son troppo avanti....
Ahem, se io fossi curioso? ;-)))
-- 
  But i still haven't found
  what i'm looking for					(U2)

music ha scritto:

Sbaglio?
Ho installato e fatto, finalmente, funzionare clamav-milter settando 
OnInfected Blackhole che dovrebbe avere lo stesso effetto del DISCARD di 
amavis.
Va bene?

 Va bene?
Se è quel che desideri, va anche bene, ma se clamav prende una cantonata
o se il mittente della mail infetta è un utente vero e non un worm
solitario (raro, ma capita) non se ne accorge nessuno, nè il mittente nè
il destinatario.
Se lo fai lavorare in reject non sbagli, fidati.


 
Sai cos'e'?
Se metto in reject la mail viene bloccata in partenza e allora sai 
quante telefonate del tipo "la posta non funziona......perche' non 
spedisce?" ecc. ecc.
Preferisco discard, se spedisconon virus ..zzi loro.

 Preferisco discard, se spedisconon virus ..zzi loro.
Come ti pare, ma sappi che con il reject abilitato sugli MSA da oltre un
paio d'anni e svariate centinaia di utenti ad usarlo/usarli, di
"chiamate" ne abbiamo ricevute sì e no un paio.
Che sono utili agli utenti stessi, nella peggiore delle ipotesi, perchè
gli fan capire che qualcosa sul loro computer non va come dovrebbe.
L'unica cosa peggiore di un utente con un trojan sul PC è l'utente con
un trojan sul PC e un provider che non glie lo dice.


 Preferisco discard, se spedisconon virus ..zzi loro.
Ce l'ho in reject da più di un anno e non ho avuto alcun problema.
Se il virus viene inviato da uno worm no problem, se è un utente reale si 
becca il bounce e/o la finestrella su outlook.
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 
e allora lo metto in reject anche io.

 e allora lo metto in reject anche io.
Tra l'altro, giusto per puntualizzare, tutte le RFC coinvolte nell'SMTP 
specificano che una mail, una volta accettata, deve essere consegnata o 
deve generare un errore.
Non si può buttare nel cesso una mail così, giusto per fare.
Max

 deve generare un errore.
Junk mail is war. RFCs do not apply. (cit.)
Però è pur vero che liddove è possibile evitarlo, è prassi da evitare
come la peste.


 Junk mail is war. RFCs do not apply. (cit.)
Parole sante.
Max

 Junk mail is war. RFCs do not apply. (cit.)
Standing ovation :)