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

Queste sono le statistiche aggregate dello spam rifiutato da
attila.bofh.it
 tra queste date:
Aug 5 06:50:58
Sep 2 06:53:44
Al momento della generazione di queste statistiche, il server era
protetto (nell'ordine) da queste DNSBL:
ip.private-dnsbl.bofh.it
zen.spamhaus.org
list.dsbl.org
combined.njabl.org
bhnc.njabl.org
dul.dnsbl.sorbs.net
1997408 78.33% Bad HELO
 316831 12.43% DNSBL 
pbl-xbl.spamhaus.org
 156177  6.12% Client host rejected
  41534  1.63% DNSBL 
ip.private-dnsbl.bofh.it
  14389  0.56% DNSBL 
dul.dnsbl.sorbs.net
   8865  0.35% Recipient address rejected
   3584  0.14% Relay access denied
   3211  0.13% DNSBL 
list.dsbl.org
   1696  0.07% Sender address rejected
   1637  0.06% Bad pipelining (Client host)
   1207  0.05% header checks
   1039  0.04% DNSBL 
bhnc.njabl.org
    953  0.04% DNSBL 
sbl.spamhaus.org
    633  0.02% Need FQDN address
    307  0.01% DNSBL 
rhs.private-dnsbl.bofh.it
    210  0.01% DNSBL 
combined.njabl.org
    148  0.01% Bad pipelining (Helo command)
     78  0.00% body checks
     15  0.00% Bad pipelining (Data command)
      8  0.00% Need FQDN address (recipient)
      1  0.00% Other
2549931        TOTAL
Rejected headers:
    474 39.27% keep your viruses for yourself (ZIP)
    440 36.45% Your mailer is not RFC 2047 compliant
    291 24.11% no executable attachments allowed
      2  0.17% do not send stupid bounces
Rejected bodies:
     78 100.00% keep your viruses for yourself (hidden iframe)
Rejected HELO commands:
1091978 54.67% generic HELO hostname
 767199 38.41% IP literal in HELO hostname
 107530  5.38% unqualified HELO hostname
  20349  1.02% Invalid name
   4789  0.24% fake IP literal in HELO hostname
   3913  0.20% using my own HELO hostname
   1650  0.08% forged HELO hostname
Popular DNSBL listings:
    343 35.99% SBL 45881
    125 13.12% SBL 58086
     90  9.44% SBL 50454
     70  7.35% SBL 49465
     53  5.56% SBL 57926
    272 28.54% others (59 different)
Popular local source-based rejections:
  82405 52.76% we do not accept mail from dynamically-assigned addresses
  45441 29.10% too much spam from this network
  25180 16.12% Too much spam from CHINANET
   2370  1.52% non accettiamo posta da IP dinamici
    428  0.27% Too much spam from China Railways
    290  0.19% Too much spam from 
chinamobile.com
     63  0.04% Too much spam from 
gwbn.net.cn
Most rejected networks:
 126401  4.96% 
88.224.0.0/11
  60455  2.37% 
83.0.0.0/11
  28842  1.13% 
85.96.0.0/13
  25977  1.02% 
71.160.0.0/11
  25130  0.99% 
85.140.0.0/15
  18115  0.71% 
81.212.0.0/14
  15687  0.62% 
85.104.0.0/14
  13700  0.54% 
81.128.0.0/11
  13184  0.52% 
86.128.0.0/10
  11855  0.47% 
80.48.0.0/13
  11772  0.46% 
121.128.0.0/10
  11692  0.46% 
84.56.0.0/13
  10458  0.41% 
41.201.192.0/18
  10333  0.41% 
59.0.0.0/11
   9605  0.38% 
84.96.0.0/13
   9400  0.37% 
91.76.0.0/14
   9103  0.36% 
58.8.0.0/14
   8505  0.33% 
189.136.0.0/13
   8447  0.33% 
91.122.0.0/16
   7578  0.30% 
218.160.0.0/12
   7561  0.30% 
86.64.0.0/12
   7511  0.29% 
124.120.0.0/15
   7325  0.29% 
72.64.0.0/13
   7250  0.28% 
88.152.0.0/14
   7078  0.28% 
86.0.0.0/11
   6740  0.26% 
41.221.16.0/20
   6652  0.26% 
88.0.0.0/11
   6631  0.26% 
190.48.0.0/14
   6405  0.25% 
86.128.0.0/13
   6372  0.25% 
90.0.0.0/12
   6060  0.24% 
71.112.0.0/13
2036821 79.92% others (19950 different)
Most rejected AS:
 202521  7.95% 9121
 105792  4.15% 19262
  78153  3.07% 5617
  59056  2.32% 4766
  46527  1.83% 8151
  46236  1.81% 4134
  43427  1.70% 8359
  40186  1.58% 2856
  35780  1.40% 3215
  30422  1.19% 5089
  27411  1.08% 3209
  25384  1.00% 3462
  25157  0.99% 4837
  22795  0.89% 15557
  20572  0.81% 8167
  19925  0.78% 7738
  17344  0.68% 8551
  17012  0.67% 5462
  16988  0.67% 6830
  16980  0.67% 9829
  16978  0.67% 7470
  15911  0.62% 6147
  15433  0.61% 3352
  15319  0.60% 27699
  15273  0.60% 9498
  14921  0.59% 6713
  14073  0.55% 21021
  13930  0.55% 209
  13782  0.54% 22927
  13528  0.53% 3269
  13328  0.52% 3320
  12547  0.49% 6739
  12451  0.49% 8997
  12292  0.48% 22047
  11838  0.46% 7132
  11504  0.45% 12741
  11475  0.45% 20115
  11320  0.44% 9318
  10860  0.43% 28573
  10740  0.42% 33774
  10674  0.42% 9141
   9993  0.39% 8402
   9867  0.39% 33287
   9555  0.37% 9143
   9388  0.37% 16338
   9311  0.37% 9737
   9075  0.36% 5610
   9038  0.35% 33651
   8767  0.34% 17864
   8740  0.34% 4755
   8561  0.34% 12479
   8412  0.33% 7029
   8384  0.33% 6849
   8333  0.33% 4788
   8196  0.32% 4713
1247180 48.94% others (5405 different)
-- 
ciao,
Marco

Marco d'Itri ha scritto:

Mi sono riletto le statistiche di marzo...
Avevi come totale 349493!
cosa può giustificare un così evidente aumento di spam?
Mi immagino che (come sul mio server) le email "buone" non siano aumentate 
in questo modo, giusto?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
After I run your program, let's make love like crazed weasels, OK?

 non siano aumentate in questo modo, giusto?
A meno che .. non abbia modificato alcune delle regexp; in
tal modo, alcune mail che prima passavano, ora vengono
bloccate e questo modifica i valori; vedi ad esempio le cifre
relative a "Bad HELO"; oltre a questo.. beh, devi anche tenere
in conto che sia lo "storm worm" e quella ciofeca di "PDF spam"
contribuiscono ad aumentare i volumi di immondizia

ObiWan ha scritto:

azz. ma son quasi 10 volte...
io da fine marzo a fine aprile ero sui 780000 rifiuti, il mese scorso, 
adesso quasi il doppio, ma a 10 volte non ci arrivo..
per i pdf prevedo di arrivare a 3000 respinti/mese quindi l'incremento è 
ancora non molto grande
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
What the world *really* needs is a good Automatic Bicycle Sharpener.

 quindi l'incremento è ancora non molto grande
già che ci siamo.. che ne pensi delle sigs di sanesecurity ?

Le mie statistiche di settimana scorsa:
(generate con 
http://sourceforge.net/projects/plogpy/
 )
from    ['Aug', '26', '06:48:04']
to      ['Sep', '2', '06:47:53']
  53847 DNSBL 
pbl.spamhaus.org
;
  18429 DNSBL 
xbl.spamhaus.org
;
   6355 Sender address rejected
   5196 Relay access denied
   4466 Need FQDN address (recipient)
   3743 Recipient address rejected
   2468 DNSBL 
dul.dnsbl.sorbs.net
;
    833 DNSBL 
sbl.spamhaus.org
;
    701 DNSBL 
list.dsbl.org
;
    304 Bad HELO
    197 ETRN Rejected
     30 DNSBL 
dnsbl.njabl.org
;
      2 attachment type not allowed
  96571 TOTAL FILTERED MAIL
  76308 TOTAL DNSBL FILTERED MAIL (79.02 %)
  16417 TOTAL GREYLISTING DELAYS
   8699 TOTAL POSTED MAIL ON 105270 ATTEMPTS (8.26 %)
   8699 TOTAL POSTED MAIL ON 121687 ATTEMPTS (INCLUDE GREYLISTING) (7.15 %)
** Most Blocked Sender IPs - Top 20 **
    863  0.764%    10.0.0.30
    716  0.634%    66.0.94.247
    485  0.429%    203.79.114.25
    461  0.408%    195.112.246.113
    455  0.403%    193.41.7.36
    445  0.394%    200.127.52.26
    432  0.382%    61.8.79.115
    429  0.380%    60.50.101.57
    428  0.379%    85.107.98.158
    370  0.327%    85.99.164.82
    357  0.316%    82.63.163.135
    303  0.268%    67.154.42.242
    290  0.257%    193.41.7.21
    289  0.256%    70.52.205.78
    282  0.250%    71.36.150.133
    275  0.243%    125.26.39.71
    269  0.238%    89.133.92.70
    233  0.206%    80.70.22.2
    228  0.202%    85.98.47.25
    223  0.197%    12.10.250.111
** Most Blocked Mail by Sender Domain - Top 20 **
   2384  2.110%    --empty_source_address_found--
   1650  1.460%    
hotmail.com
    802  0.710%    
poste.it
    716  0.634%    localhost.local
    669  0.592%    
bancaintesa.it
    619  0.548%    
collettivoanimalista.org
    515  0.456%    
icqmail.com
    485  0.429%    
gollum.limedesign.co.nz
    475  0.420%    redjane
    465  0.412%    
bancaroma.lt
    455  0.403%    
arcoiris.tv
    433  0.383%    
mibank.com
    418  0.370%    
bancoposta.poste.it
    357  0.316%    
SLEGNO.IT
    340  0.301%    localhost.localhost
    308  0.273%    
libero.it
    302  0.267%    
yahoo.com
    290  0.257%    
logosquotes.org
    289  0.256%    tonka.tonka
    286  0.253%    
163data.com.cn
-- 
Gerolamo

 
Per ora non un falso positivo su (scribble, scribble,calc) 703
L'unico caso dubbio (l'ip era di un cliente) era colpa di chi aveva ricevuto 
l'email (prima che attivassi i filtri) e poi aveva forwardato il tutto ad un 
collega (dopo  l'attivazione dei medesimi) senza neanche controllare cosa ci 
fosse dentro
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
The only way to get rid of a temptation is to yield to it.
		-- Oscar Wilde

 controllare cosa ci fosse dentro
Beh, la cosa mi consola e conferma i dati da me rilevati (zero falsi
positivi, qualche PDF "passato") di sicuro per quanto mi riguarda
quelle sigs hanno risolto in gran parte il problema del PDF spam
e (spero) aiuteranno anche a risolvere quello dei "PDF worms"
per completezza...
http://www.google.com/search?hl=en&q=pdf+spam
http://www.google.com/search?hl=en&q=pdf+worm
al peggio non c'è mai fine <g>

 1997408 78.33% Bad HELO
Questo controllo comprende il reverse DNS ?
Lo chiedo perche' sto' cercando di capire se il controllo del reverse dns
sia una pratica diffusa e quanto sia utile/importante far configurare i
record PTR dal prorio provider di connettivita' corrispondenti ai record MX
dei propri server di posta.
A me pare che non sia essenziale, attualmente il mio provider non ha i
record PTR corrispondenti a 
mioserver.miodominio.it
 eppure non ho alcun
reject in proposito.
-- 
Stefano L.

reject in proposito.
Dipende da dove manda posta e quanta ne manda.
-- 
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

 Dipende da dove manda posta e quanta ne manda.
In italia, qualche migliaio al mese.
Ci sono paesi in cui e' piu' controllato che altrove ?
Ho gogolato in fretta e mi pare d'aver capito che da noi e' una pena.
Attualmente con interbusiness (HDSL e/o ADSL) ho speranza di fargli
impostare il rDNS ?
Grazie.
-- 
Stefano L.

 ho speranza di fargli impostare il rDNS ?
si, sul sito trovi un modulo da stampare ed inviare via fax

 impostare il rDNS ?
Se hai contratti business (e l'HDSL sicuramente lo è) sì.

 si
no
Nel senso che č meglio non farlo.
Per quel che riguarda l'italia (all'estero leggo essere messi meglio,
ma non ho esperienza diretta) č meglio mettere a posto il proprio reverse,
ma evitare di filtrare quelli che non ce l'hanno a posto.
A meno che non si sia disposti a perdere un quantitativo di posta,
seppur minoritario, non nullo.
-- 
Gerolamo 

 tale controllo.
beh, un check per la validità del PTR potrebbe essere ad esempio...
^\d+\.\d+\.\d+\.\d+$|^[^\.]+\.?$|\d{1,3}(\.|-|x)\d{1,3}(\.|-|x)\d{1,3}|dynamic|ddns|
dns.org
 
^c-.*\.comcast\.net 
^(cpe|rrcs)-.*\.(biz|res)\.rr\.com 
^(pool|static)-.*\.verizon\.net 
\.abo\.wanadoo\.fr 
\.dhcp\..*\.charter\.com 
\.dynamic\.hinet\.net 
icip\.rima-tde\.net 
\.user\.veloxzone\.com\.br 
c.*\.virtua\.com\.br 
^host.*\.(business|retail)\.telecomitalia\.it 
p.*\.dip\.t-dialin\.net 
\.(internetdsl|adsl|sdi)\.tpnet\.pl 
\.(adsl|fbx)\.proxad\.net 
^s[0-9].*\.shawcable\.net 
\.(onocable|user)\.ono\.com 
\.(pppoe|pptp)\.mtu-net\.ru 
pool.*\.uni2\.es 
-cust.*\.ntl\.com 
^bzq-.*\.bezeqint\.net 
\.(cable|stb)\.blueyonder\.co\.uk 
\.(customer|dial-up|dsl)\.telesp\.net\.br 
-[0-9]{2,3}-.*\.qwest\.net\.br 
\.bb\.netvision\.net\.il 
\.(dsl|dial|ipd)\.brasiltelecom\.net\.br 
\.rev\.gaoland\.net 
\.pools\.arcor-ip\.net 
(ppp|static|revip).*\.
asianet.co.th
 
\.dynamic\.qsc\.de 
\.o\.pppool\.de 
^pop-.*\.freesurf\.ch 
^du.*\.as15444\.net 
\.point\.ch 
\.net4all-dns\.com 
\.emv1\.net 
\.(dial|cable|adsl)\.wanadoo\.nl 
\.messagereach\.com 
\.premiereglobal\.com 
\.venturedirect\.com 
\.xmr.*\.com 
^ns.*\.ohv\.net 
\.mhs\.ch 
\.dynamicIP\.rima-tde\.net 
\.dyn\.optonline\.net 
^zaq.+\.zaq\.ne\.jp 
^user.+\.mindspring\.com 
\.ipt\.aol\.com 
\.access\.telenet\.be 
^host.*\.telecom\.net\.ar 
^[^\.]*[0-9]{6}#changed 5 to 6 due to Yahoo Servers 
^([^\.]+\.)?[0-9][^\.]*\.[^\.]+\..+\.[a-z] 
^[^\.]*[0-9]\.[^\.]*[0-9]-[0-9] 
^[^\.]*[0-9]\.[^\.]*[0-9]\.[^\.]+\..+\. 
^(dhcp|dialup|ppp|adsl|DSL|dial|dynamic|host|HOST|pool|user|PC|pop|POP|client)[^\.]*[0-9] 
ciao

 caso di servers con parecchio traffico significa che è consigliabile
Heh. C'è da dire che postfix effettua i check DNS/rDNS già in seguito
alla connect, dato che nella migliore delle ipotesi gli servono per
stabilire se un IP è autorizzato o meno al relay, con il risultato che
1) quando applichi il ruleset, i dati sulla risoluzione inversa e alla
sua validazione in zona diretta già li hai, quindi applicarci
restrizioni viene a gratis, con un "impegno" molto inferiore a quello di
una regexp... :-P
2) le risoluzioni "impegnative e lente" che dici le fa ugualmente, e
anzi, pensandoci, non so nemmeno se siano disabilitabili :-D
Altri SMTP non so: ringraziando il cielo non uso sendmail oramai da anni
(e non rimpiango affatto... :-D ) e gli altri SMTP mai usati...

 da anni (e non rimpiango affatto... :-D ) e gli altri SMTP mai usati...
Ah beh, sendmail non lo uso neanche io; mi chiedo solo come gestisca
la cosa SA; so però per certo che esistono filtri che applicano i checks
nella sequenza di cui sopra (prima HELO, poi il resto)
ciao

> beh, un check per la validità del PTR potrebbe essere ad esempio...
dimenticavo, ci sarebbero anche queste (non le ho provate però)
http://www.linuxmagic.com/opensource/anti_spam/dynamic_regex/generate_regex.php

 
http://www.linuxmagic.com/opensource/anti_spam/dynamic_regex/generate_regex.php
$ grep -vc ^# generic-rdns-patterns
1845
;-)

 ;-)
Ah beh :) cmq facendo lo stesso check con un'elenco generato
dall'URL di cui sopra  (selezionando "no" per le varie opzioni)
viene fuori un count pari a 2154 credo che il tuo 1845 sia cmq
più "valido" dato che ad occhio le regexp generate sono meno
"generiche" e probabilmente meno ottimizzate delle tue ;-)
resta il fatto che quell'elenco potrebbe comunque essere utile
per migliorare le regexp esistenti

 procedere con gli altri
Il traffico DNS e' davvero minimo e non capisco le tue preoccupazioni.
Mi sembra come suggerire di togliere le spazzole del tergicristallo
quando non piove per migliorare l'aerodinamica e abbassare i consumi.
Al massimo in certi casi puo' costare qualche secondo di latenze,
comunque trascurabile rispetto ad altre fonti di ritardo nella
trasmissione di messaggi.
Inoltre, i logs senza rDNS sarebbero una lettura serale molto meno
interessante ;-)
furio

 viene fuori un count pari a 2154 [...]
Non so chi mantenga quelle di 
linuxmagic.com
, ma penso che l'autorita' 
mondiale in materia sia Steven Champeon ( 
http://enemieslist.com/
 ).
furio

 interessante ;-)
ah beh, da questo punto di vista non posso non darti ragione :-D

 tempo tutto sommato non proprio trascurabile 
Considerando che da lunedì scorso gran parte dei bot in circolazione
tengono connessioni appese per il mero gusto di farlo, quei pochi decimi
di latenza del'interrogazione DNS (peraltro cachate dal resolver) sono
l'ultimo dei problemi di chi mantiene server SMTP di una certa
dimensione, IMHO...

 per migliorare le regexp esistenti
Più che altro non tutte le zone inverse "generiche" sono utilizzabili:
alcune sono usate per la mappatura di netblock destinate a server
dedicati, e dati prelevati da sorgenti ersterne spesso m'han dato
problemi con queste.
Quindi mi son risolto a tralasciare l'ipotesi di usarle. Le nostre
crescono cmq ogni giorno di un paio di righe, in funzione di quanto
giunge sulle spamtrap...

 una certa dimensione, IMHO...
beh.. metti un timeout sulla connex ed in caso di inattività della stessa, 
resettala dopo un certo tempo; oppure, se vuoi proprio essere cattivo,
creati un programmino che spoofi il mittente (quello che tiene appesa
la sessione) e che invii al TUO server un RST così il tuo server chiuderà
la connessione e l'altro resterà appeso :-D

 possano comunque essere usati per indicare la stessa cosa  :)
Lo sono (e a mio parere impropriamente), ma non era questa la perplessità.
Quello che non capisco è cosa intendi quando affermi:
"effettuare il check rDNS solo dopo aver controllato la validità
dell'HELO riduce anche il carico sui DNS che tengono in piedi le RBL"
- La query rDNS va dal resolver all'autoritativo per la zona inversa
(con le eventuali deleghe nel mezzo).
- Le query DNSBL vanno dallo stesso resolver ai server autoritativi per
la DNSBL del caso (con le eventuali deleghe nel mezzo, che però hanno
effetto solamente una volta al dì si e no, dato che una volta cachate le
riusi a manetta fino a scadenza).
Quando parli dei "DNS che tengono in piedi le RBL", a me vien da pensare
a questi ultimi (i mirror delle DNSBL), che però non sono in alcun modo
coinvolti dalla query rDNS.
Ti riferivi forse al resolver in quanto tale?

 Steven Champeon ( 
http://enemieslist.com/
 ).
niente da eccepire; ho soltanto scritto che quella lista 
di regexp potrebbe comunque essere interessante/utile 
al fine di migliorare le regexp già in uso

 RBL"
spiego, supponi di voler controllare un IP su "zen"; il controllo
effettuato, assumendo che l'IP sia 127.0.0.2 sarą rappresentato
da una query di tipo "A" per 
2.0.0.127.zen.spamhaus.org
 (ok tutto
questo lo sai); questa query viaggerą dal tuo resolver (o DNS) al
DNS che tiene in piedi la zona (ai DNS) il che causa un "minimo" 
carico a questi ultimi; ovviamente nel caso di mailservers e/o di
spamming-ip "conclamati" il carico/traffico viene ridotto grazie al
meccanismo di caching delle risposte DNS, ma, nel caso di spam
proveniente da bots la cache "non funziona" il che significa che i
DNS che forniscono le risposte alle tue query riceveranno un tot
di richieste; a questo punto, evitando il check rDNS iniziale ed
effettuando tale check solo dopo altri controlli (es. HELO) si evita
di inoltrare ai DNS tali queries rDNS riducendo il carico verso
questi ultimi

 questi ultimi
Quindi, ti riferivi ai resolver locali.
Il tuo ragionamento è indubbiamente vero, ma prendi una
installazione-tipo, che faccia uso di una decina di DNSBL.
Ogni DNSBL si porta appresso una query (in realtà 2 nel caso peggiore:
oltre alla query A dimentichi la query TXT, per il testo di ritorno).
Il che significa che ogni mail trattata attraverso DNSBL coinvolge 10-20
query DNS, nella migliore delle ipotesi.
Aggiungi roba tipo check SPF, check sugli MX del dominio, check sui
record NS del dominio e tutta un'altra serie di query che un ruleset
sufficientemente elaborato normalmente fa (ricordiamo che parliamo di
situazioni "ad alto carico", dalla tua premessa iniziale) e non ci
allontaniamo troppo dal vero se affermiamo che ogni mail *transitata* si
porta appresso 20-30 query DNS (con relative eventuali escalation sulle
deleghe) solo per quanto concerne i dati in envelope (tralasciamo
eventuali check del body, che possono portare a valori ben più alti).
Questo quadro implica che, per risentire in qualche modo del carico
dovuto alle 2 query necessarie a rDNS e sua validazione, il resolver
dovrebbe stare lavorando al 5-8% dai suoi limiti operazionali, il che è
un po' *tanto* tirato...
Per dire: son d'accordo che quella risoluzione apporta un carico sui
resolver, ma IMHO quel carico è talmente minimale che, se la sua
presenza è in qualche modo "ingombrante", c'è un problema strutturale
ben più grave che non la presenza di un paio di query DNS non essenziali...

 problemi con queste.
beh, e' praticamente impossibile indovinare con esattezza se un reverse 
si riferisce ad una connessione dinamica. Cosi' come per i server email 
che non hanno reverse, queste connessioni *non puoi bloccarle* - a meno 
di non stare tutto il giorno a fare whitelisting... Come sai, molti 
mailserver utilizzano allegramente, e con soddisfazione (almeno cosi' 
dicono molti sysadmin che provi ad avvertire), zone inverse "generiche" 
su netblock statici assegnati dal loro provider...
Io ho 'comunque' una routine con delle regexp abbastanza complesse che 
/provano/ ad identificare se un reverse e' generico/dinamico con un buon 
grado di accuratezza [1], ma ovviamente non vuole essere perfetto. Uso i 
risultati positivi solo per "trattare peggio" le connessioni.
Ad esempio (ma e' solo un esempio):
-) le faccio passare per la greylist (evito i delay incondizionati)
-) faccio in modo che Spamassassin, in seguito (se riesce a passare), 
aggiunga almeno un punto al messaggio;
-) ecc...
ciao
1) per info: controllo la connessione SMTP a livello di 'RCPT TO' su un 
deamon che ho scritto in perl
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 ^(([a-z\d][a-z\d\-]*)?[a-z\d]\.)+[a-z]{2,6}$','(.*)
scusami, sara' che e' ora di pranzo, ma non ho capito la parte dopo il $
ciao


 che non hanno reverse, queste connessioni *non puoi bloccarle* - a meno
Qui in realtà parlavo proprio di rDNS *generici*, non di dinamici. Per
quelli ci son mappe a parte, che son decisamente più corpose:
b$ grep -vc ^# access-dyn*
access-dyn:3729
access-dyn-pcre:793
Il fatto di avere dei pattern che matchano le rDNS generiche non è per
il blocco in sè, ma è un elemento che viene utilizzato in svariati punti
del ruleset, ad esempio per il matching sulle helo-string...

 dimensione, IMHO...
Ciao,
visto che ne parli, mi aggancio qui :)
molto in piccolo, ho notato anch'io questo comportamento e stavo
pensando di abbassare da 180 a 120 secondi il timeout sulla mia porta
25.
Ho alzato un po' le connessioni riservate agli host in whitelist e
quelli che hanno passato il delay imposto in greylist, quindi dando
meno connessioni agli "sconosciuti".
Secondo te, posso aver problemi col timeout a 120 secondi ? qual è il
limite inferiore prudenziale ?
tnx,
Gabriele

 limite inferiore prudenziale ?
Mah, già 180 era fuori RFC, dato che prevedono 300...
Come dicevo in altra sede, non ho trovato problemi portandolo fino a 60s
sec, e altri ben più credibili del sottoscritto affermano che 45s sia
approssimativamente il limite da rispettare per esser un minimo
conservativi...
Poi che da qualche parte salti fuori un problema con questi limiti è
sempre possibile, ma credo sian casi da mosca bianca...

 mantenuta dai resolver locali, che spesso ha un effetto molto maggiore
<cut>
SCUSA
ho scritto delle ca**ate; si stava parlando di check su reverse-DNS ed
io invece mi sono messo a pensare ai lookups DNSBL; hai ragione tu,
il check rDNS non è un problema (almeno entro certi limiti) e comunque
non "carica" i DNS

Grazie a tutti, e' stato molto istruttivo.
Comunque adesso i miei rDNS sono settati.
E' bastato telefonare all'assistenza e dopo aver spiegato (6 o 7 volte)
che cosa volevo fare e che ''no, non e' il mio DNS che devo configurare ma
il vostro'' mi hanno passato un tecnico che ha fatto al volo la cosa.
Sia per interbusiness che per alicebusiness.
-- 
Stefano L.