Newsgroup: it.comp.os.linux.sys
Titolo: Exim e greylist

Uso con quasi successo greylistd accoppiato ad exim
per gestire le greylist.
C'ï¿œ perï¿œ un problema: non ï¿œ possibile calcolare la greylist
su una subnet piuttosto che su un singolo IP.
Dal punto di vista teorico sarebbe corretto, ma si vengono
a generare dei ritardi alquanto fastidiosi, come nel caso di
twitter, linkedin ed altri grossi portali.
Questo capita perchï¿œ inviano la prima email di verifica, che
viene correttamente greylistate e respinta al mittente.
Il mittente riprova dopo un po, ma con altri ip. Anch'essi vengono
greylistati e respinti. Riprova per la terza volta con un terzo
ip e cosï¿œ via, per molto ,molto molto tempo.
Risultato?
- nel caso di twitter/linkedin, la mail non viene verificata perchï¿œ
il portale 'si stufa' di provare e dice che ci sono problemi
- nel caso di mail legittime inviate da grossi operatori, l'utente
riceve la mail dopo ore, molte ore.
Idee su come risolvere questo mezzo-problema?
Non vorrei disattivare le greylist. (adesso le ho impostate a 50
secondi per cercare di bypassare linkedin, ma non mi sembra una grande
idea)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 linkedin, ma non mi sembra una grande idea)
Io le ho disattivate tempo addietro.
Non ne sento la mancanza.

 idea)
E' un problema che ho avuto anch'io in passato (specialmente con indirizzi
da Google).
La mia soluzione (visto che non mi e' possibile calcolare la rete a
partire da un IP) e' stata di fare il controllo SOLO sulla coppia
"mittente-destinatario" al posto che sulla tripla
"mittente-destinatario-IP".
Il sistema funziona da 3 anni buoni e non ho mai avuto problemi.
E non mi sembra di ricevere piu' Spam del normale...
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
Io uso sqlgrey (
sqlgrey.sf.net
)  e è possibile utilizzare anche una subnet
per il greylisting.
 Giovanni

 "mittente-destinatario-IP".
E come hai risolto? Con quale software?
greylistd pu� salvare la coppia mittente/ip e non mittente/destinatario.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la


 Non ne sento la mancanza.
Si, forse hai ragione, ma non avendo tempo
di verificare le variazioni dello spam nel
disattivare le greylist, per non saper ne
leggere ne scrivere, le tengo attive.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la



Io con Greylist ho ritrovato la fede, la pace e la speranza.
"Non avrai altro frontend di me" cita uno dei miei comandamenti.
Amen.
No, scherzi a parte, sego una percentuale di spam incredibile con il 
greylisting. Per me sarebbe impossibile disattivarlo.
Ctrix ora come stai? Solo con spamassassin o hai implementato altro?

 stai? Solo con spamassassin o hai implementato altro?
Spamassassin lo uso solo per taggare quello che alla fine comunque 
passerà (lo spam via relay e non direct to mx va per la maggiore).
Uso pesante di RBL e di inspection della mail, fondamentalmente.

 Uso pesante di RBL e di inspection della mail, fondamentalmente.
Come me, io però non ho nemmeno SA installato.
Solo e soltanto RBL, pubbliche e mie. Più il greylist che
sta rompendo un po i maroni ultimamente.


 Non ne sento la mancanza.
Idem.
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Idem.
E vabbè, allora provo a disattivarle anche io.
Sempre meglio una greylist in meno ma una mail
legittima in più, che l'opposto.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


> e di inspection della mail, fondamentalmente.
con cosa fai l'ispezione?
Personalmente ho timore ad utilizzare le RBL, mi generano continuamente 
tonnellate di falsi positivi. Anche solo SORBS.
ciao.

 Idem.
OK, pero` (correggetemi se sbaglio), le greylist hanno, come vantaggi, 
che:
1- costano poco computazionalmente
2- non hanno falsi positivi (a meno di server malconfigurati dei 
mittenti, ma...)
Di negativo hanno solo che ritardano di qualche minuto l'invio delle 
email. E, volendo fare il pelo all'uovo, che sono facilmente ingannabili.
Non conviene comunque usarle come "prima scrematura", visto soprattutto 
che costano sicuramente meno di una interrogazione a una RBL o, peggio, 
di una analisi del contenuto delle mail?
Bye.

 email. E, volendo fare il pelo all'uovo, che sono facilmente ingannabili.
Anche qui non è proprio vero.
Ritardano, ma di quanto dipende dal mittente.
Alcuni server riprovano ad inviare subito dopo pochi secondi, poi
dopo ore.
In tal caso, o metti le greylist configurate per tardare di X secondi
(dove X < 60) oppure rientri già nel terzo invio da parte del mittente
che magari avviene dopo alcune ore.
in tal caso, la mail tarda di ore.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 in tal caso, la mail tarda di ore.
Yep...


 Yep...
Che è una *grossa* rottura di maroni per chi deve rispondere
al telefono. Lascia pure che la mail non è una chat, ma vallo
a spiegare gli luser che hanno inviato questa mattina da
$SuperProviderCheRitentaDopo50Secondi non hanno ancora ricevuto
nulla perchè il primo retry rientrava ancora in greylist, il
secondo ha un fallback su un server differente, quindi genera
una nuova tripla, il terzo retry viene fatto dopo 6 ore con la
tripla differente ed il quarto retry vien fatto dopo 12 ore.
Surreale? No, capita più volte al giorno, tutti i giorni.
(Questo spiega perchè avevo messo 50 secondi, ed ero tentato
a mettere 30 o 20 secondi)


 ha scritto nel messaggio
news:hsriho$5s6$
1...@nnrp.ngi.it

Io sego una percentuale altissima di bot con le greylist.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 da parte di clienti.
Cos� senza guardare nei log non mi sembra di avere problemi n�
con linkedin n� con twitter, per� io metto in whitelist tutti quelli che
hanno passato il greylisting.
Stavo pensando di aggiungere alla whitelist del greylisting anche
gli ip di 
dnswl.org
.


 gli ip di 
dnswl.org
.
Il whitelisting lo fanno in automatico quasi ogni software di
greylisting, il problema perï¿œ non ï¿œ whitelistare un IP, bensï¿œ
evitare il listing di interi pool associati allo stesso mittente.
Come ho scritto, se twitter invia con 10 IP sorgenti, rischia
di finire in list 10 volte di fila (come infatti capita) perchï¿œ
il primo invio lo farï¿œ con un IP, il secondo con un altro, il
terzo con un terzo e cosï¿œ via, finchï¿œ non si scassa i maroni
e comunica agli utenti che il server di destinazione ha problemi.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la


 Io sego una percentuale altissima di bot con le greylist.
Anche da me fanno un ottimo lavoro (alta percentuale di merda che se
ne resta fuori), se poi qualcuno ha il fuoco al culo consiglio di dire
al corrispondente di spedire il messaggio due volte, la seconda dopo
un paio di minuti oppure se telefona per chiedere se e` arrivato, che
era urgente, di rispedire.
Andrea

 era urgente, di rispedire.
ROTFL.
Mi dai il numero di Twitter?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la


 ne resta fuori)
Il fatto � che di mezzi per tenere fuori i BOT ne ho a bizzeffe,
efficaci "a pi� strati":
http://bofhskull.wordpress.com/2009/09/17/misurazioni-inaspettate/
Oramai lo spam da botnet si "tiene fuori" con estrema facilit�: la parte
difficile � lo spam relayed attraverso mailserver leciti
(hotmail/gmail/etc in primis), e quello passa il greylisting per
definizione.
Il risultato � che dopo aver disabilitato il greylisting l'efficacia dei
filtri non � cambiata di una virgola, ma la responsivit� del flusso di
posta come percepito dell'utenza � di certo migliorata.


 Mi dai il numero di Twitter?
Ma da Twitter devono ricevere e-mail per lavoro?
Andrea

 posta come percepito dell'utenza è di certo migliorata.
Certamente si`. Ne sai/pensi qualcosa di questo oggetto,
Anti-Spam SMTP Proxy:
http://sourceforge.net/apps/mediawiki/assp/index.php?title=Main_Page
Andrea

 e comunica agli utenti che il server di destinazione ha problemi.
Hai considerato l'idea di usare 
dnswl.org
? ho appena visto che
listano sia twitter che linkedin.


 Ma da Twitter devono ricevere e-mail per lavoro?
Da linkedin volendo si.
Perï¿œ ti sfugge in piccolissimo particolare:
le mail non le devi usare obbligatoriamente per
lavoro. Io devo offrire un servizio, non importa
se il cliente deve iscriversi alla mailinglist
interna del CERN sulla ricerca delle particelle
atomiche o alla newsletter di Mirabilandia, io
la mail la devo recapitare comunque.
E se twitter non riesce ad inviare, diventa
automaticamente un mio problema che devo risolvere.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la


 listano sia twitter che linkedin.
No, adesso la attivo.


 No, adesso la attivo.
Fammi sapere come ti ci trovi...


 Fammi sapere come ti ci trovi...
Certo che se avessero gestito il listing in maniera differente
sarebbe stato meglio. Hanno questo formato:
127.0.X.Y
Dove X ï¿œ la categoria, Y il livello.
Il che rende impossibile filtrare in base al livello di listing,
visto che X varia sempre.


 visto che X varia sempre.
Il senso � usarle via spamassassin, ma la mia idea era quella
di scaricare il generic- e inserirmelo nel db del greylisting come
whitelistato, ripetendo l'operazione ogni tot per aggiornare.


 
http://sourceforge.net/apps/mediawiki/assp/index.php?title=Main_Page
A parte il sentito-dire, no...


 saranno iscritte almeno una volta.
Non è la mail di iscrizione, è la mail di *verifica* periodica (e 3)
Anche io sono iscritto, da mesi, poi l'altro giorno sia linkedin che
twitter mi han segnalato (sia a me che ad altri 5-6 clienti) di non
essere riusciti ad inviare una mail al mio indirizzo utilizzato in fase
di registrazione.
Vado a vedere i log e vedo due tentativi, entrambi in greylist,
provenienti da ip differenti. Fatto il primo, listato, fatto il secondo,
listato anche lui, poi basta.

 secondo, listato anche lui, poi basta.
Ho appena 'seguito' nei log un post di twitter.
14:05:30 invio, Doesn't Exists Block, errore temporaneo.
14:06:31 invio su MX secondario, ricevuto, inoltrato al primario.
Forse il fatto di avere due MX in qualche strano modo aiuta a
minimizzare il problema?


 minimizzare il problema?
Ne ho due anche io.


 non ti � chiara?
Ho scritto "un post" e volevo scrivere "una mail", il contenuto non
lo conosco.
Comunque lasciamo perdere che � meglio, � evidente che sono
informazioni che non ti servono.


 informazioni che non ti servono.
Be, ho scritto che non arrivano *SOLO* le mail di verifica
account, *TUTTE* le altre arrivano.
Il che probabilmente ha anche un senso, e' molto probabile
che twitter (e compagnia bella) diano un limite al numero di
errori (temporaneo o permanente che sia) nelle mail di verifica
per evitare strani giri da parte del ricevente.
Tutte le altre mail, sempre da twitter, arrivano regolarmente,
solo quelle della verifica non mi arrivano, perchï¿œ si scontrano
2 volte sulla greylist e non ho mai visto un terzo retry.
Comunque ora ho rimosso la greylist. Se Bertoncello volesse
rendere pubblico il suo codice per fare il check su mittente e 
destinatario gli sarei grato, eviterei di reinventare la ruota.
Alla fin fine, ha la stessa validitï¿œ di una greylist, chi non
segue la greylist, non seguirebbe nemmeno il check sulla doppietta,
l'ip ï¿œ solo una discriminante in piï¿œ che mi sta arrecando non
pochi grattacapi.



mi associo al quesito, magari se qualcuno a volo sapesse come fare il 
check solo su mittente e destinatario anche su postgray, non sarebbe male.
ciao.

 check solo su mittente e destinatario anche su postgray, non sarebbe male.
Me lo sto facendo in perl.
Non sono un programmatore perl (anzi, a dire il vero
ï¿œ la prima volta che metto mano ad un codice perl) e
sto impiegando piï¿œ tempo del solito, ma sono poche righe
di codice.
poi lo posto.


 di codice.
Allora, il codice ï¿œ quasi pronto, ma c'ï¿œ una cosa che non
so risolvere.
Io ho:
my $sock = new IO::Socket::INET (
    LocalHost => 'localhost',
    LocalPort => '7070',
    Proto => 'tcp',
    Listen => 1,
    Reuse => 1,
);
while ($client = $sock->accept()) {
    while ( <$client>) {
       chomp($_);
       # tante cose...
       print $client "grey\n";
    }
}
In pratica, devo aprire un socket (e funziona), devo
mettermi in ascolto di un input da parte del client
(e funziona) e devo rispondere al client con "grey".
Perï¿œ, non riesco a rispondere. Nelle prove in locale
sembra funzionare, lo attivo su Exim ed exim non rileva
la risposta.
Non si fa con un semplice
print $client "testo\n";
una comunicazione server -> client?


 una comunicazione server -> client?
$|=0; # da mettere all'inizio del programma
Se non funziona, 
 !google perl autoflush 

  !google perl autoflush 
Grazie, domani provo.
Ma di default perl bufferizza l'output?

 la risposta.
ma se devi accederci da un solo exim non fai prima ad usare qualcosa
del tipo
${perl{greyFunction}{$local_part}{$domain}}
(invece di creare, accedere, etc.. ad un socket)?
ciao,
stefano

 (invece di creare, accedere, etc.. ad un socket)?
Non proprio perch� i server che devono accedere sono 3.
Il pezzo di codice sar� in ascolto su un server remoto e
non direttamente sugli MX in modo da avere in comune
le greylist.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la


  !google perl autoflush 
Funziona, o almeno così sembra.
Però solo la prima volta.
Ad esempio, mi collego, invio i dati, il server
risponde correttamente.
Chiudo, faccio una nuova connessione, invio i dati
ed il server non risponde più. Devo uccidere e
ricreare il socket per farlo ripartire.
Cosa può essere? Secondo me ci vuole un reset
della connessione una volta inviato l'output.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 volta inviato l'output.
Senza codice non saprei dirti.
Ad occhio e croce non fai l'accept o lavori su $client della connessione 
precedente.

 precedente.
L'ho postato il codice.
le parti rilevanti son quelle postate, il resto son solo
dei gran print e degli if (più un piccolo pezzo di codice
che legge e scrive da un db berkeley)