Newsgroup: it.news.net-abuse
Titolo: postgrey comincia a .......

..........mostrare i suoi limiti.
Nel senso che per alcuni mesi di utilizzo era riuscito ad eliminare 
quasi il 90% dello spam, ora pero', giorno dopo giorno, lo spam sta 
ricrescendo e non si tratta solo del phishing di 
poste.it

music ha scritto:

Non è un problema di limiti di postgrey (o sqlgrey o altro greylister): se gli spammer riescono a 
mettere le mani su account smtp auth usano dei server validi che quindi onorano la richiesta di 
reinvio senza problemi
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Oh Dad!  We're ALL Devo!

 senza problemi
Esatto; infatti il greylisting (o delaying se preferisci) non nasce con
lo scopo di filtrare "tutto lo spam" ma solo quello proveniente da
spambots ossia lo spam del tipo "fire & forget"   questo significa
che sebbene il greylisting possa essere utile al fine di eliminare
una buona percentuale di spam di tale tipo, lo stesso filtraggio non
può essere utilizzato da solo ma andrebbe utilizzato insieme ad
altri checks (es. DNSBL, HELO, SPF, AV)

 altri checks (es. DNSBL, HELO, SPF, AV)
Sempre parlando di SPF: c'è qualcosa che sia il "contrario" di SPF? Ovvero
che, dato l'IP  del server che invia, controlli se puoi inviare per quel
dominio, usando gli stessi dati di SPF?
-- 
Vide

 dominio, usando gli stessi dati di SPF?
Eh?
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGSFK/8THo01J+SBERAhVFAJ9/cLYy9wbefTiY6GVesbChnjx5rQCeNnf4
uZB6XJT/XsP2TByMo9f8OIo=
=B8Ny
-----END PGP SIGNATURE-----



Uh.. come "il contrario di SPF" ? Quello che hai appena descritto
è il funzionamento canonico di SPF.. ossia.. SPF permette di sapere
se un dato "mittente" sia autorizzato ad inviare email per un
determinato
dominio.. mi sa che hai le idee confuse.. oppure hai formulato male la
tua domanda
vabbè :)

 vabbè :)
Mi son spiegato male :) 
SPF parte dal presupposto che vuole controllare che chi dice di essere
pi...@topolinia.com
 invii da un server permesso. Ma se 
topolinia.com
 non ha
un record SPF, il controllo non serve a nulla.
Quando parlo di "contrario" intendo dire che uno risolve l'IP numerico del
server e trova un record che gli dice "questa IP può inviare 
topolinia.com
,
pippo.it
 e 
pluto.us
", per cui se si prova a inviare una mail
come "
paperopoli.com
" ti risponde picche.
Questo per difendersi da diffusione di spam nel caso di server bucati.
O è una stupidata e basta e avanza smtp auth?
-- 
Vide

 mail come "
paperopoli.com
" ti risponde picche.
a parte che nel record SPF è possibile anche specificare indirizzi IP;
in ogni caso, se un server tenta di inviarmi una email da
"
topolinia.com
"
e se "
topolinia.com
" ha un record SPF; sarà facile verificare se quel
server sia o meno autorizzato a tale invio; supponi di avere un record
SPF di questo tipo
v=spf1 mx ip4:1.2.3.4 -all
a questo punto, solo i servers indicati come MX per "
topolinia.com
" o
l'host posto ad IP 1.2.3.4 saranno autorizzati all'invio di email per
conto
del dominio; ora.. o io non ho capito la tua domanda.. o tu non hai ben
chiaro il funzionamento di SPF :)

 conto
Sí ma poniamo l'esempio che ti bucano il server e cominciano a sparare spam
attraverso il tuo mail server come se fosse posta tua, ma con indirizzi di
envelope chiaramente diversi (@
poste.it
, per esempio), io proprietario del
server bucato devo sperare che il dominio scelto dallo spammer abbia un SPF
valido che faccia bloccare le mail illegali inviate dal mio.
Se invece io a monte avessi un record che dice che i *miei IP* non possono
inviare mail per *altri domini* al di fuori di quelli che voglio io,
risolverei questo caso. SPF questo *non* lo fa.
(ovvio che la situazione migliore è che non ti buchino i server, questo è
fuori di dubbio)
-- 
Vide

 risolverei questo caso. SPF questo *non* lo fa.
Lo fa gia' di suo l'MTA....
-- 
L'universita' americana di Berkeley
ha prodotto due importanti invezioni: l'LSD e Unix.
Credo non sia una coincidenza.
                                          Jeremy S. Anderson

 Lo fa gia' di suo l'MTA....
Uh?
Io col il mio server posso presentarmi con un from qualsiasi, per
inviare posta all'esterno, se ho superato le altre fasi di
autenticazione.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 autenticazione.
Era quello che intendevo, o mi sono perso qualche passaggio?
-- 
Son giunto alla conclusione che, almeno una volta nella vita, bisogna
usare Windows a fondo, perche' e' un'esperienza che rende uomini.
Almeno, io, dopo, ho sempre due palle cosi'.
                                                            Leonardo 
Serni

 Era quello che intendevo, o mi sono perso qualche passaggio?
O io non ti ho capito, o tu non ti sei capito. :-)
Io ho capito che l'OP vorrebbe che l'MTA (mittente o destinatario) non
lasciasse transitare mail da pippo@dominiodiverso se l'MTA sorgente e'
di @altrodominio.
E tu hai detto che lo fa gia' di suo l'MTA.
Ecco, a me non risulta che "lo faccia gia' di suo".
La possibilita' che io non abbia capito un'apascio c'e, ovviamente, e
nemmeno tanto recondita.


 nemmeno tanto recondita.
La possibilità che il ragazzino e/o lo zio non ci abbiano capito un 
apascio e' inversamente proporzionale alla quantità di spammer di 
Verona che frequentano inna ;)
-- 
Devi sapere che l'Universo puo' essere visto come una battaglia fra i
sistemisti, che cercano di realizzare sistemi a prova d'idiota, e Dio
che crea idioti sempre piu' sofisticati. Inutile dire che, per ora, Dio 
sta vincendo.                                           Leonardo Serni

 e questo mi risulta che gia' si possa fare con postfix ad esempio.
Ok, però se è un server bucato (anche solo da web application, senza andare
a forare direttamente l'MTA) tu arrivi a postfix con le credenziali giuste
per inviare quello che ti pare... o mi son perso qualche opzione di
main.cf
? (possibilissimo)
-- 
Vide

 
main.cf
? (possibilissimo)
Da 
main.cf
 quanto a quello puoi limitare parecchie cose, comprese
"quelle". Tuttavia, affidare queste cose solamente all'MTA stesso e alle
sue configurazioni non ha senso, dato che parliamo di macchina bucata:
le configurazioni si cambiano, una volta che ci si è dentro.
Di norma, piuttosto, ha senso che solo l'MTA in quanto tale sia
autorizzato a contattare la porta 25 di chicchessia, e che in toto la
macchina sia "attaccata" a qualcosa che possa monitorarla e bloccarla
qualora si scosti dal comportamento "normale".
L'ipotetico "record SPF inverso" che ipotizzi ha una funzionalità
presocchè nulla, dato che non vieta in alcun modo alla macchina bucata
di spammare (o phishare) il mondo usando un envelope-sender tra quelli
consentiti (si veda il comportamento dei phishers su 
poste.it
 nel
momento in cui questa ha pubblicato record SPF)...
Bye
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGSxGu8THo01J+SBERAjcfAKCt61D+Ct/Rg7kPxuABSTQBc8LtmACguBSy
nuMSJ8ann7P+/xe5P7hmG4Q=
=12KH
-----END PGP SIGNATURE-----

 momento in cui questa ha pubblicato record SPF
beh .. più che altro la cosa è conseguenza di una vera
genialata da parte di Poste Italiane; hanno utilizzato le
stesse credenziali sia per le carte che per l'accesso
al servizio email; a quel punto i phishers, avendo i dati
delle carte ci hanno messo poco ad usarli anche per
inviare emails di phish autenticandosi presso i servers
di 
poste.it
 :P

 stesse credenziali sia per le carte che per l'accesso
Quello è risolvibile (e a quanto pare anche risolto, dato che non
riscontro più quel tipo di mail) molto banalmente iniziando a monitorare
quello che i propri utenti fanno, segando account di conseguenza.
No, mi riferivo molto banalmente al fatto che nel momento in cui
poste.it
 ha pubblicato SPF, tutte le attività di phishing che usavano
questo dominio a campo mittente hanno semplicemente switchato all'uso di
altri domini, simili ed esistenti (come ad es. postA.it), mantenendo
poste.it
 come dominio in header From: (che tanto l'utente se ci deve
cascare ci casca uguale...).
Con il risultato che la presenza del record in questione non ha spostato
il problema di granchè...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGSx288THo01J+SBERAhZ0AKDGB35LUW6LZ6plx7sZ+AB/zLegHQCghfvI
qkTVuvefTuubRdCYa04dvlY=
=rkot
-----END PGP SIGNATURE-----