Newsgroup: it.news.net-abuse
Titolo: bloccare gli spam con un timeout ?

Questa notte sia io che una collega abbiamo ricevuto zero spam, per
quanto il server ne abbia rigettati alcune centinaia via DNSBL.
Tuttavia poi un collega e' venuto a riferirmi un altro problema (i PC
che usavano tale server come smtp-server con Pine avevano un delay). Ho
trovato che il delay si applicava anche a qualsiasi invio unix-to-unix
(mailx -v) dal server a macchine locali, che un telnet sulla porta 25
del server rispondeva con il messaggio iniziale dopo un delay pure di
2-3 minuti, e che il syslog aveva un numero notevole di "did not issue
MAIL/EXPN/VRFY/ETRN".
La diagnosi tentativa e' stata che potesse essere successo qualcosa a
uno dei server DNSBL. E infatti 
monkeys.com
 non risponde piu'
(contrariamente agli annunci che avevano detto che sarebbe rimasto
attivo a livello di DNS con le zone vuote). Appena ho commentato le
entries relative a 
monkeys.com
 in 
sendmail.cf
 il delay e' scomparso.
In seguito ho fatto una statistica dei dominii per cui negli ultimi
giorni sono stati emessi i "did not issue MAIL/EXPN/VRFY/ETRN", ed essi
sono TUTTI di spammatori o sospetti tali (non sono tra i domini
accademici con cui abbiamo regolarmente a che fare).
Ho fatto la seguente illazione (che gradirei qualcuno confermasse o
meno) : i normali sendmail si connettono e attendono per un timeout
abbastanza lungo la connessione iniziale (e quindi passano). Gli
spammatori invece usano altri s/w e vanno "a mitraglia" e quindi se la
destinazione va in timeout lasciano cadere subito la connessione.
Se cio' fosse vero, mi domandavo se non fosse fattibile introdurre
artatamente un piccolo delay (si puo' fare a livello di opzioni in
sendmail.cf
 ?) in modo da far cadere le connessioni degli spammatori
(questo assume che loro siano interessati a invii BULK molto rapidi e
quindi non riaggiustino i loro parametri di timeout).
Ha senso ?
-- 
----------------------------------------------------------------------
nos...@ifctr.mi.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.

destinazione va in timeout lasciano cadere subito la connessione.
È corretta. Ma nota che anche alcuni mail server importanti si
comportano così, quindi devi fare in modo che il timeout sia solo sulla
prima connessione da un certo IP.
-- 
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

 prima connessione da un certo IP.
Alcuni server "seri" sono anche un po' troppo rapidi nel passare all'uso del
secondo MX in caso di "ritardo" del primo...dunque o si ha pieno controllo
su tutti gli MX del proprio dominio o altrimenti si rischia di veder
recapitati molti messaggi provenienti dal relay di backup del proprio ISP
CiaU
--
Alex

 ha pieno controllo su tutti gli MX del proprio dominio o altrimenti
Siamo un dominio accademico e i nostri due MX ce li gestiamo noi


 entries relative a 
monkeys.com
 in 
sendmail.cf
 il delay e' scomparso.
I secondari di 
proxies.relays.monkeys.com
 _sono_ attivi con zona vuota,
tuttavia non rispondono piu' gli autoritativi di 
monkeys.com
 a Surewest
che contengono le deleghe.
Ora domando a Ron, perche' non credo proprio che questo fosse previsto.
furio ercolessi


ns4.monkeys.com
 e' su (anche se ns5 no), e non dovrebbero esserci 
timeouts.   Forse e' stato qualche glitch di rete.
furio ercolessi