Newsgroup: it.news.net-abuse
Titolo: [STATISTICHE] spam rifiutato da attila.bofh.it (luglio 2005)

Queste sono le statistiche aggregate dello spam rifiutato da
attila.bofh.it
 tra queste date:
Jul 10 06:54:09
Aug 7 06:51:25
Al momento della generazione di queste statistiche, il server era
protetto (nell'ordine) da queste DNSBL:
sbl-xbl.spamhaus.org
list.dsbl.org
korea.services.net
dul.dnsbl.sorbs.net
combined.njabl.org
l1.spews.dnsbl.sorbs.net
1089070 70.61% Bad HELO
 242159 15.70% DNSBL 
xbl.spamhaus.org
 135396  8.78% DNSBL 
dul.dnsbl.sorbs.net
  29426  1.91% DNSBL 
list.dsbl.org
   9422  0.61% Client host rejected
   5980  0.39% Recipient address rejected
   5932  0.38% Relay access denied
   5828  0.38% header checks
   5094  0.33% DNSBL 
combined.njabl.org
   4214  0.27% DNSBL 
l1.spews.dnsbl.sorbs.net
   4019  0.26% DNSBL 
korea.services.net
   2496  0.16% DNSBL 
sbl.spamhaus.org
   1803  0.12% DNSBL 
dnsbl.njabl.org
    640  0.04% Need FQDN address
    384  0.02% Sender address rejected
    354  0.02% body checks
     45  0.00% Other
      2  0.00% Need FQDN address (recipient)
      1  0.00% Bad pipelining
1542265        TOTAL
Rejected headers:
   2636 45.23% Your mailer is not RFC 2047 compliant
   1030 17.67% do not send stupid bounces
    999 17.14% keep your viruses for yourself (ZIP)
    808 13.86% no executable attachments allowed
    322  5.53% Gibe-F/Swen.A worm
     29  0.50% Your mailer is not RFC 2047 compliant (UTF-8)
      4  0.07% Message content rejected
Rejected bodies:
    301 85.03% keep your viruses for yourself (hidden iframe)
     44 12.43% do not send stupid bounces
      9  2.54% keep your viruses for yourself (bmp attachment)
Rejected HELO commands:
 833633 76.55% fake IP literal in HELO hostname
 204961 18.82% unqualified HELO hostname
  47966  4.40% using my own HELO hostname
   1349  0.12% forged HELO hostname
   1161  0.11% Invalid name
Popular DNSBL listings:
   1257 18.73% SPEWS 3198 (
blueyonder.co.uk
)
   1238 18.45% SPEWS 2963 (comcast/attbi)
    311  4.63% SPEWS 1297 (
Telesp.net.br
)
    300  4.47% SPEWS 3199 (
seamail.go.com
)
    235  3.50% SPEWS 3150 (tiscali)
    188  2.80% SBL 29359
    171  2.55% SBL 15575
    169  2.52% SBL 27986
    156  2.32% SBL 28922
    153  2.28% SPEWS 3126 (
telemar.net.br
)
    137  2.04% SPEWS 2919 (
embratel.net.br
)
     95  1.42% SBL 28333
     93  1.39% SBL 24218
     85  1.27% SBL 18068
     83  1.24% SBL 19306
     79  1.18% SBL 19307
     78  1.16% SPEWS 703 (misc16)
     64  0.95% SBL 27947
     57  0.85% SBL 28936
     56  0.83% SBL 28852
   1705 25.41% others (252 different)
Popular local source-based rejections:
   8529 90.52% Too much spam from CHINANET
    465  4.94% non accettiamo posta da IP dinamici
    291  3.09% Too much spam from 
ethome.net.tw
    109  1.16% Too much spam from 
gwbn.net.cn
     18  0.19% Too much spam from 
chinamobile.com
     10  0.11% others (3 different)
Most rejected networks:
  17746  1.16% 
82.32.0.0/12
  15717  1.02% 
218.144.0.0/12
  13066  0.85% 
221.144.0.0/12
  12602  0.82% 
222.96.0.0/12
  12017  0.78% 
12.0.0.0/8
  11156  0.73% 
84.128.0.0/10
  10783  0.70% 
83.0.0.0/11
   9755  0.64% 
82.0.0.0/11
   9382  0.61% 
211.200.0.0/13
   9376  0.61% 
211.216.0.0/13
   9100  0.59% 
211.208.0.0/13
   8782  0.57% 
219.0.0.0/10
   8766  0.57% 
220.0.0.0/10
   8719  0.57% 
220.88.0.0/13
   8568  0.56% 
220.72.0.0/13
   8479  0.55% 
213.184.224.0/22
   7970  0.52% 
60.208.0.0/12
   7524  0.49% 
61.72.0.0/13
   7409  0.48% 
211.224.0.0/13
   7400  0.48% 
82.224.0.0/11
   7028  0.46% 
61.52.0.0/14
   6885  0.45% 
211.192.0.0/13
   6771  0.44% 
220.120.0.0/13
   6740  0.44% 
81.96.0.0/12
   6556  0.43% 
221.160.0.0/13
   6424  0.42% 
59.0.0.0/11
   6173  0.40% 
71.96.0.0/12
   6147  0.40% 
222.136.0.0/13
   6068  0.40% 
222.232.0.0/13
   5995  0.39% 
222.112.0.0/13
   5919  0.39% 
219.128.0.0/13
   5766  0.38% 
218.160.0.0/12
   5426  0.35% 
220.80.0.0/13
   5348  0.35% 
221.0.0.0/14
1244474 81.02% others (14155 different)
Most rejected AS:
 149362  9.72% 4766
 100417  6.54% 4134
  93528  6.09% 4837
  61144  3.98% 9318
  34538  2.25% 17676
  31209  2.03% 22909
  27346  1.78% 9277
  27107  1.76% 6478
  21871  1.42% 5089
  20121  1.31% 7738
  19466  1.27% 5462
  19174  1.25% 22047
  18710  1.22% 33287
  18377  1.20% 10318
  16698  1.09% 6830
  16603  1.08% 3786
  15486  1.01% 3462
  15410  1.00% 11427
  15128  0.98% 5617
  14715  0.96% 19262
  14354  0.93% 9908
  14132  0.92% 3320
  13662  0.89% 4812
  13539  0.88% 27699
  13163  0.86% 7018
  12945  0.84% 4814
  12139  0.79% 20115
  11608  0.76% 4670
  11263  0.73% 9583
  10823  0.70% 3215
  10508  0.68% 8167
  10456  0.68% 6147
  10367  0.67% 4230
  10188  0.66% 9304
   9730  0.63% 7015
   9613  0.63% 19548
   9385  0.61% 12322
   8554  0.56% 4713
   8536  0.56% 20852
   8274  0.54% 9121
   8041  0.52% 28573
   7883  0.51% 8151
   6726  0.44% 12271
   6478  0.42% 11351
   6355  0.41% 3269
   6334  0.41% 9812
   6263  0.41% 9824
   6219  0.40% 11426
   5987  0.39% 13156
   5923  0.39% 3352
   5807  0.38% 16338
   5791  0.38% 9457
   5748  0.37% 9394
   5328  0.35% 4788
   5256  0.34% 8708
   5254  0.34% 22927
   5214  0.34% 8551
   5211  0.34% 7643
   5099  0.33% 10091
 461471 30.04% others (3443 different)
-- 
ciao,
Marco

 1089070 70.61% Bad HELO
Cosa hai come filtri sull'HELO?
a me blocca circa un 12% del totale, il grosso lo fa xbl.spamhaus
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Credete che i verdi vadano in bicicletta per tenere pulita la Citta'?
Vi sbagliate: vanno in bicicletta per tenere pulita l'auto.
		-- Gabriella Ruisi

 
Si, ma l'ordine in cui applichi quale č?!?
E cosa seghi, in HELO?

 E cosa seghi, in HELO?
Che fai, ribalti la domanda :-) ?
comunque quelle non conformi alla rfc821
E già con questa mi son fischiati i telefoni un bel po'.
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
- Ai bambini buoni, la dolce Euchessina.
- E a quelli cattivi?
- Che spingano!
		-- Anonimo

Cosa hai come filtri sull'HELO?
Le solite cose. I domini e IP della macchina e questo:
/^\d+\.\d+\.\d+\.\d+$/          REJECT fake IP literal in HELO hostname
/^[^\.]+\.?$/                   REJECT unqualified HELO hostname
-- 
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

 
La prima ce l'ho, la seconda mi blocca un pacco di roba buona, mi trovo 
degli helo di clienti legittimi tipo <ART> che evidentemente non č rfc 
compliant.. che robaccia č che esce cosě, outlook standard?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Se dentro il PCI facessero delle elezioni libere, il 45% voterebbe
Democrazia Cristiana come in Ungheria.
		-- Vincino

 compliant.. che robaccia č che esce cosě, outlook standard?
Okkio: l'utilizzo di restriction di questo genere presuppone che
gli MX che le applicano *non* siano le MSA per i client, oppure che il 
ruleset sia costruito in modo da avere permit_mynetworks prima delle 
restriction stesse.
Un conto č pretendere un comportamento sensato dai server altrui, un 
altro aspettarsi che i client di posta sian fatti (e configurati) con la 
testa...

 testa...
ugh... debo ancora imparare molto....
I miei server fanno entrambe le cose (relay per i client e server smtp)
Quando avrò tempo (e soldi!!) dividerò un po' i server
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Il futuro?  Ho gia' pronto il mio terzo album, ma non uscira' mai perche'
e' brutto.  Il prossimo dunque sara' direttamente il quarto.
		-- Francesco Baccini

 Quando avrò tempo (e soldi!!) dividerò un po' i server
BEh.
I tuoi client li salvi con $mynetworks.
Quelli dei clienti, se usano sasl, non puoi salvarli con 
- permit_sasl_authenticated
prima degli helo_checks ??
Max

 prima degli helo_checks ??
Yeah...


Ok, però devo applicare le restrizioni dopo l'rcpt: mi sembrava di di 
aver letto che in questo modo il proceso si appesantisce, oppure ricordo 
male?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Le donne non hanno mai niente da dire.  Ma lo sanno dire cosi' bene.
		-- Oscar Wilde

 
Duh?
Perchè, ora dove le applichi?!? O__o
Usi smtpd_delay_reject = no ?
Cattiva idea...
Peraltro, se non aspetti l'rcpt non puoi nemmeno escudere destinatari 
dal filtraggio (AKA: se non lo stai già facendo, escludi l'utenza 
postmaster e una utenza di contatto ben pubblicizzata!!!), visto che 
quando operi il reject ancora non sai chi sono.
E non hai nei log a chi era diretta la mail (e quindi quando devi capire 
perchè qualcuno non sta ricevendo, ciao...).
Cattiva, cattiva idea, IMHO.
La differenza di carico macchina è peraltro talmente irrisoria da non 
giustificare una simile scelta (posto che non l'ho mai misurata, eh).

 giustificare una simile scelta (posto che non l'ho mai misurata, eh).
Vista la quantità di spam che vedo "stoppata" il gioco vale decisamente 
la candela.
Mi rimane da fare uno scriptino che inserisce anche i vari domini 
presenti sul server e sono a posto-
Vuol dire che se passate da firenze, mi avvertite qualche giorno prima e 
passo a fare rifornimento di baladin :-)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Io posso sollevare un elefante con una mano sola. Ma dove lo trovo, un
elefante con una mano sola?
		-- Leopold Fechtner

 passo a fare rifornimento di baladin :-)
Domani va bene ??
Max


'Azzo, il fornitore mi sa che è in ferie .-(
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
A Milano 3 ci sono delle zanzare cosi' grosse che quando c'e' la nebbia
le fanno atterrare alla Malpensa.
		-- Gene Gnocchi

        
cbl.abuseat.org
Contenuta in XBL.


 
dul.dnsbl.sorbs.net
Usando questa per l'indirizzo 84.220.79.179, mi da che è un indirizzo 
(Dynamic IP Ranges) tra quelli bloccati (infatti mi restituisce 127.0.0.10).
Non so se prima di me qualcuno l'ha utilizzato per inviare spam, ma un 
ip dinamico di tiscali non dovrebbe essere listato.
Sono io che (da niubbo) interpreto male i dati o la lista non è molto 
affidabile?
bye
-- 
Gestione Ottica - Gestionale per Ottici e Programmi Gratuiti su:
http://www.nicolaottomano.it
Sinapsi Antispam. Antispam Gratuito.
http://www.nicolaottomano.it/sinapsi.htm
email spamtrap: 
spam...@nicolaottomano.it

 affidabile?
La prima che dici.  DUL per definizione lista i dinamici, quindi il
listing e' assolutamente corretto.
Va da se' che non usi una DUL quando scavi sotto la prima Received.
furio

furio ercolessi ha scritto:

Innanzitutto ti voglio ringraziare per la risposta a questo e all'altro 
thread.
Dunque, al momento, non sapendo chi contatta chi (e di conseguenza 
qual'è il server incriminato), controllo tutti gli ip di tutti i Received.
Quindi sicuramente incappo in ip dinamici, il che mi fa pensare che 
dovrei eliminare l'uso della DUL... e in tal caso oltre a sbl-xbl (di 
spamhaus), quale potrei utilizzare (che si dimostrino affidabili e con 
pochi falsi positivi)?


 pochi falsi positivi)?
CBL, e di conseguenza XBL, e' disegnata per lavorare su un server
e verificare gli IP che *contattano* il server in questione; altri
usi sono pericolosi.
Mi spiego: supponiamo che l'IP $IP sia dinamico, ad un certo istante 
emetta spam/virus e finisca in XBL, dopo un paio di giorni l'utente si
stacca e $IP va in mano a qualcun altro che supporremo pulito.
XBL terra' probabilmente $IP listato per un po' anche quando e'
in mano al nuovo utente.  Tuttavia il nuovo utente non spedira' la sua 
posta usando i server del suo ISP.  Pertanto non verra' generalmente 
bloccato da chi usa XBL.  Se per quello , nemmeno l'utente originario
aveva la sua posta bloccata da XBL; solo la spazzatura dalla sua
macchina veniva bloccata.
Quindi se usi XBL su tutte le Received avrai sicuramente molti piu' FP che 
con l'uso normale, e la cosa probabilmente diventa devastante nel momento
in cui inserisci liste senza expire automatico (DSBL ad esempio),
e che quindi col tempo sono quasi diventate quasi delle DUL per i
network ad alta densita' di abuso.
Se vuoi usare XBL in modo canonico e sicuro devi fare in modo che il tuo 
s/w riconosca la Received che rappresenta la consegna dal proxy 
all'MX del dominio destinatario e consideri solo quella.
furio

furio ercolessi ha scritto:

Grazie mille, ora provo a lavorare su un algoritmo ottimizzato...
Ci sto provando ma non è semplice.
Mediamente vi sono 4-5 Received negli header. Supponendo che 1 o 2 siano 
fasulle, posso provare a lavorare solo sulle ultime 2 o 3 (in ordine 
cronologico).  Oppure posso prendere in considerazione di controllare 
solo chi ha contattato il provider (e se è un IP dinamico, sicuramente 
sarà un bot).
Stanotte ci dormo sopra e vediamo cosa ne esce.


 
Lascia fare.. considera che se analizzi una mia email ti trovi come
received 127.0.0.1 e quindi molti programmi di filtraggio si possono 
inalberare, ma che colpa ne ho se l'av su postfix si configura così?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
- Lei e' bellissima!  Mi vuole sposare?
- Dipende.  Lei russa?
- No, ma potrei imparare.
		-- Dennis O'Neil

 inalberare, ma che colpa ne ho se l'av su postfix si configura cosě?
Si, ho notato... Poichč scrivo da dietro un router, noto che vengono 
messi entrambi gli ip (quello pubblico e quello privato).
Posso solo provare ad eliminare i range di ip dedicati (es. 127.x.x.x, 
192,168.x.x, ecc...)
Pian piano sto ottimizzando l'algoritmo e mi trova sempre meno falsi 
positivi.


 cronologico).
Vedo principalmente due problemi salienti in questa tecnica:
- riconoscere gli header falsi (cosa tutt'altro che banale)
- riconoscere il reale punto di immissione di una mail
Come riportava Furio un altro post, la strada apparentemente piů
applicata (ed efficace) al riguardo č la creazione di una base dati
contenente gli IP di SMTP "conclamati validi", in modo da poter
escludere a priori tutti i Received dovuti al transito attraverso questi.
Se la base dati č sufficientemente completa, ci si limita quindi a
eliminare dall'analisi tutti i Received che attestando la ricezione DA
un SMTP valido e pigliare l'ultimo (cronologicamente) proveniente da IP
non contenuto in lista.
E' chiaro che, come soluzione, non č altrettanto "out-of-the-box"
(d'altra parte, non ho mai creduto alle soluzioni out-of-the-box)...

 inalberare, ma che colpa ne ho se l'av su postfix si configura cosě?
Una bella regex con target IGNORE e le levi...

 escludere a priori tutti i Received dovuti al transito attraverso questi.
Solo se stai ricevendo la connessione SMTP diretta. Ovvero se il tuo server
SMTP e' contattato da un client considerato attendibile puoi scartare la sua
riga received e analizzare la successiva, ma se questa e' di un utente
con ip dinamico del provider che ti contatta hai poca scelta.
L'unica possibilita' e' che la tua macchina riceva la posta da un MX del TUO
provider, allora avrebbe senso scartare il Received del tuo provider, ma se
questo MX non usa nessuna RBL vale la pena pensare di cambiare ISP... :-)
La strada proposta potrebbe essere utile, ad esempio, per i clienti con ip
statico che usano l'SMTP del proprio provider per inoltrare spam e virus, ma
allora ci si lamenta col provider e se questo non prende provvedimenti lo si
banna in pieno, purtroppo spesso e' Interbusiness e quindi ci si puo' fare
poco...
ciao
Michele

Skull ha scritto:

Si, quello sicuramente (basta eliminare i range ip riservati).
Il mio problema č piů complesso. Anche se mi conviene seguire il 
consiglio che mi hanno dato: leggere solo gli IP dell'ultimo server con 
cui ho comunicato.
bye

 poco...
...a parte applicare quanto suddetto...

 del totale).
Tuttavia, nel caso di AOL e' ormai oltre l'80%.
Consiglio a tutti uno sguardo a queste otto slides di Hutzler:
http://www.nanog.org/mtg-0410/pdf/hutzler.pdf
(e anche 
http://www.circleid.com/article/917_0_1_0_C/
 )
furio