Newsgroup: it.news.net-abuse
Titolo: [Semi-OT] Ma sono stupidi?

): delivery
     temporarily suspended: connect to 
nowhere.com
[69.30.210.12]: Connection
     timed out
[CUT]
<fine>
Ma se questi cretini mandano una conferma ad un indirizzo chiaramente 
spoofato, non generano un traffico pari a quello che genera lo spam?
E il fastidio che danno è lo stesso!
O sono io che sbaglio qualcosa?
bye

 O sono io che sbaglio qualcosa?
e' corretto che sia così.
Non si ha modo di verificare che la mail sia spoofata.
Le tecniche volendo ci sarebbero, per chi le applica (spf, ad esempio).
Ma parti già male affindandoti ad aruba che ha pochissimo interesse
nell'applicare tecniche antispam, visto che *PARE* che con lo spam ci
faccia parecchi soldini (non intervenendo a bloccare i suoi clienti).
Dubito inoltre che sappiano cosa sia.
Max
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 e' corretto che sia così.
Ma anche no. Sarebbe opportuno che configurassero i loro bei serverini 
per rigettare (con reject) gli utenti sconosciuti sul socket, 
piuttosto che accettarlo in una prima fase e poi fare il bounce.

lorenzodes ha scritto:

Ma il server che ha generato l'invio poi il bounce a chi lo manda?
Al mittente...
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Vivere nel paese dei campanelli e' un vero supplizio per chi ama bussare.
		-- Alessandro Bergonzoni

lorenzodes wrote:

Dipende da come si sta comportando il presunto bot.
Se fa direct-to MX, hai ragione.
Se sta invece facendo uso di un relay, allora è il server che sta
effettuando il relay, a generare il bounce.

 Al mittente...
Il problema e' quello ben noto come 'backscatter', e si risolve
come dice Lorenzo.  Purtroppo in molti casi questo richiede
degli investimenti (per fare in modo che i server dello strato
MX sappiano quali utenti esistono e quali no, e rigettino
il massimo numero possibile di messaggi con un 5xx durante la
transazione di consegna).
La generazione di un bounce e' a carico del server che
ha ricevuto un rigetto (5xx). Di conseguenza se il network di
destinazione da' un 5xx alla periferia, la generazione
del bounce e' a carico del lato mittente.  Nella maggior
parte dei casi (trojan bots) il server SMTP che spedisce
e' quello dello spammer, che si guarda bene dall'inviare
bounce a utenti che lo spammer stesso ha falsificato come
mittenti.  Discorso analogo vale per i virus, e (si'! c'e'
anche qualche incapace che fa questo!) messaggi rimbalzati 
(anziche' rigettati) perche' classificati spam da content filters.
http://www.spamhaus.org/faq/answers.lasso?section=ISP%20Spam%20Issues#109
http://www.spamcop.net/fom-serve/cache/329.html#bounces
http://spamlinks.net/prevent-secure-backscatter.htm
http://www.quadernionline.it/spam_2004/ercolessi.html
furio

 
Mica mi torna.. L'esempio in questione č quello di mettere il tuo indirizzo 
in un'email che io invio ad un destinatario sconosciuto (diciamo 
pi...@pippo.it
), quindi il mio server chiede all'mx di 
pippo.it
 di fare il 
delivery, l'mx destinatario segnala utente inesistente ed il MIO server non 
puņ fare altro che prendere l'indirizzo del mittente e inviargli il 
messaggio d'errore: come fa a sapere il mio server che il mittente non č 
veramente furio ercolessi?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
(Parlando di un naso enorme)  Visto che lei vede solo a un palmo di naso,
potrebbe dirmi come sta mio cognato a Pechino?
		-- Steve Martin

 MIO server non può fare altro che prendere l'indirizzo del mittente e 
Non OK. :-)
Il tuo server, si becca un 5xx durante la transazione smtp.
Non fa un bounce a furio, riceve un reject, non prende nessun indirizzo
mittente e non genera nessuna mail.
Il tuo client si prende il 5xx che gli rigira il tuo server, e ti
segnala un errore in invio posta.
Nessun bounce a nessun indirizzo.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 mittente non č veramente furio ercolessi?
Il *server* nessuno.
Ma questo ragionamento *non* vale per la stragrange maggioranza dello
spam/virus, che č veicolato preferibilmente in direct-to-MX...
Vale invece nel caso il cui la mail viene routata attraverso un relayer.

 
No.. Se io invio email al *mio* server di posta lui la mette in coda e 
quando è in comodo fa l'invio.
Il client si prende 5xx quando fa direct-to-mx o l'mx è lo stesso server che 
viene usato per l'invio.
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Errare e' umano.  Ma ti fa sentire divino!
		-- Mae West

 Vale invece nel caso il cui la mail viene routata attraverso un relayer.
E fin qui siamo d'accordo. Però se lo spammer non usa troiai da spammer di 
massa ma invia in modo casalingo funziona così
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it


 
Il tuo server fa un bounce e fin qui non ci piove.
L'OP, però, porta il caso di un'e-mail, con lui come mittente (è 
falsificato) che non sono inviate da altro utente che usa il suo 
stesso server (di Aruba), ma che gli ritornano come bounce.

 
Vero, ma di rado chi invia "in modo casalingo" invia con mittente
forged, che è invece una caratteristica, di norma, di spamware.
Il 99% del "problema backscatter", in realtà non è causato da questi
casi, ma dall' accept&bounce in luogo del 550, che per svariate
questioni (SW obsolescente, architettura inadeguata, banale ignoranza,
mero menefreghismo, ecc) è applicato ancora da un sacco di parti...

 quando è in comodo fa l'invio.
Oops.
Bisogna che mi abitui a non postare a stomaco vuoto, che il neurone
e' impegnato a pensare al nutrimento, e non ragiona poi cosi' bene.[*]
Comunque, questo problema e' marginale, come ti hanno gia' detto.
Ipotizziamo:
caso 1: server legittimo.
Furio avvisa il postmaster che prende a male parole il suo utente,
o chiude il suo server che fa relay, o fa togliere il virus al suo
utente, magari bloccandogli il relay o l'smtp-auth, se non ottiene
risultati.
caso 2: server spam-friendly.
a- Normalmente su dinamico->BL-> bounce a furio non arriva nemmeno. ;-)
b- Server abusato da spammer, vedi caso 1, e al 99% anche il caso 2a.
c- Postmaster sordo, inattivo o inetto: vedi caso 2a.
[*] Beh, non e' che anche in altre condizioni, poi, ... ;-P


 faccia parecchi soldini (non intervenendo a bloccare i suoi clienti).
Ma io da aruba non mando mail.
Uso quella casella per ricevere le mail dei clienti.
La spiegazione è semplice: ho un sito hostato da aruba (che con 28 
euro/anno mi danno un servizio soddisfacente).
Ho alcune caselle email configurate su quel dominio sulle quali ricevo 
posta di clienti e amici. Non invio mail da aruba (se non in rari casi 
quando non ho l'accesso al mio pc e sono costretto ad usare webmail).
Quindi il problema (a mio avviso) non dovrebbe neanche porsi.
Non mi sembra giusto che server mal configurati generino traffico 
inutile (pari al traffico dello spam, ma all'inverso) e tralaltro non 
verso lo spammer... ma verso ignari utenti!
Solo oggi ne ho avute 5 di queste mail.
bye