Newsgroup: it.comp.os.linux.sys
Titolo: postfix - lo spam mi fa diventare isterico

Ciao a tutti,
sto combattendo lo spam ma con esiti non molto positivi.
Ho un dominio che riceve 4000 email di spam al giorno, si avete capito bene.
ecco cosa ho fatto (per favore, mi dite se è troppo rischioso?):
POSTFIX:
smtpd_recipient_restrictions =
         permit_sasl_authenticated,
         permit_mynetworks,
         reject_unauth_destination,
         reject_non_fqdn_sender,
         reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
         reject_invalid_hostname,
         reject_unauth_pipelining,
         check_helo_access pcre:/etc/postfix/helo-pcre
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
unknown_address_reject_code = 554
unknown_hostname_reject_code = 554
unknown_client_reject_code = 554
nel file helo-pcre ho impostato:
/^#/	                         550 Block
/^
miodominio.it
$/ 	         550 Block
/^mio.ip.xx.xx$/                 550 Block
/^test\d*$/                    	 550 Block
/^
mail.com
$/                     550 Block
su un firewall che fa un'ispezione le email con le seguenti RBL vengono 
taggate *SPAM* ed i client hanno la regola per spostare l'oggetto:
cbl.abuseat.org
dns.rfc-ignorant.org
list.dsbl.org
dnsbl.sorbs.org
bl.spamcop.net
sbl-xbl.spamhaus.org
sbl.spamhaus.org
spam-rbl.com
xbl.spamhaus.com
ma arriva ancora tonnellata di spam non identificata.
che faccio? *aiuto!!*

 ma arriva ancora tonnellata di spam non identificata.
Definisci "tonnellata". Se l'uso che fai di quanto sopra è corretto, 
dovresti stare segando tra il 75 e l'80% dello spam che ti arriva.
Se il motore antispam che stai utilizzando ti consente di fare URI 
inspection, aggiungi check per SURBL e dovresti riuscire ad arrivare 
senza grosse difficoltà tra il 95% e il 98%.
Del 2% che rimane può richiedere parecchio lavoro in più, e bisogna 
vedere se ne vale la pena.
Ma non è nemmeno detto che sia necessario: domini diversi ricevono spam 
diverso e con "spettro di distribuzione" diverso, e quel 2% potrebbe in 
realtà essere, nel tuo caso, una mail al mese...
-- 
http://bofhskull.wordpress.com/

 vedere se ne vale la pena.
se rimane un 2% io ci metto firma!!!
grazie davvero skull! :)

 forse ho cercato male.
Mboh. Mi parli di "un firewall che tagga le mail", il che già mi fa 
storcere il naso...
Per URI-inspection io uso milter-link, che per me funziona benone:
http://www.snertsoft.com/sendmail/milter-link/
Se però inizi a voler implementare una architettura di filtraggio da 
zero, forse l'uso di un milter con spamassassin può essere più 
flessibile, se i numeri (inteso come flusso di mail e conseguente "peso" 
computazionale) te lo consentono...
-- 
http://bofhskull.wordpress.com/

 che faccio? *aiuto!!*
SPF e Greylist, tanto per cominciare.
E magari anche il blocco delle connessioni non autenticate che arrivano da
IP dinamici (fonte del 99% dello Spam).
E, giusto per stare sul tranquillo, blocco di tutte le connessioni che non
danno un HELO/EHLO fqdn.
Se non ricevi E-Mail da Newsletter o MailingList, puoi anche pensare di
implementare un controllo sul DomainKey (OK, non riempitemi di bastonate!
Lo so benissimo che DomainKey e' stato fatto proprio per ovviare ai
problemi di SPF, pero' rimane il fatto che il 90% dei gestori di
Newsletter e MailingList massacrano gli Header e fanno fallire il
controllo, OK?).
Per i primi due, ho scritto (tanto tempo fa) una piccola guida per
l'implementazione con Exim e Postfix.
La trovi su 
http://www.soft-land.org/
Per i DomainKeys e gli altri blocchi non saprei proprio dirti come fare
con Postfix...
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

Ciao Luca, grazie anche a te delle info.
Pensavo di implementare un sistema di graylisting solo notturno.
Gli utenti accettano volentieri lo spam "diurno" perchè diluito. Ma 
arrivare la mattina e trovarsi 200 email in casella da controllare non è 
bello.
Come posso schedulare questa cosa? Con dei cron che copiano banalmente 
due 
main.cf
 / 
master.cf
 e danno un service postfix restart alle 21,00 e 
alle 8,00 ?

 alle 8,00 ?
E' un'idea. Insensata, secondo me visto che devi poi mantenerti due
configurazioni in sincrono, ma e' pur sempre un'idea...
Detto fuori dai denti, non vedo proprio nessun motivo per il quale
Greylist non dovrebbe essere sempre attivo...
Al limite, questo si!, puoi istruire Postfix per non greylistare le E-Mail
che danno una risposta POSITIVA al controllo SPF (quindi: il mittente
offre informazioni SPF e l'IP del mittente e' tra gli IP ammessi).


 Greylist non dovrebbe essere sempre attivo...
bhč, ci sono 20 persone che sparano 1500 email al giorno e con i loro 
clienti utilizzano questo strumento tipo chat per botta e risposta sui 
loro servizi... il greylist introduce un indubbio ritardo che spesso non 
puň essere tollerato. Questo č un motivo.
Per assurdo potrei anche stoppare il servizio postfix dalle 21,00 alle 
8,00, le email reali arriverebbero comunque la mattina dopo. Una specie 
di greylist un po' piů rozza :)

 di greylist un po' piů rozza :)
MOLTO rozza...


> Vai un po' a vederti COSA e' Greylist... Il ritardo e' SOLO la prima volta.
ah, pensavo lui rifiutasse qualsiasi email. Quindi graylist chiede il 
reinvio solo la prima volta e poi mette il mittente in una specie di sua 
whitelist definitiva?

 whitelist definitiva?
Non definitiva, ma puoi impostare tu per quanto tempo.
Bye.

writethem wrote:

Non tanto il mittente, quanto l'IP da cui la mail è stata ricevuta. 
Almeno, se è applicato come si deve.
Greylisting permette di verificare se lo specifico IP che ti sta 
mandando la mail è un mailserver "vero", facendogli re-incodare la mail.
Una volta che ha dimostrato una volta di essere un mailserver, 
continuare a metterlo alla prova è privo di senso...
-- 
http://bofhskull.wordpress.com/

writethem ha scritto:


Piu' o meno!
Leggiti l'articolo che scrissi su 
soft-land.org
! E' spiegato tutto
dettagliatamente, con tanto di esempi di configurazione per Exim e Postfix!
Comunque, in breve: la tripla mittente-destinatario-IP_del_mittente viene
verificata.
Se e' gia' conosciuta si lascia passare l'E-Mail, altrimenti si da un
Temporary Reject.
Poi imposti tu per quanto tempo vuoi tenere in memoria quella tripla
(ovviamente inteso come "tempo dall'ultima volta che e' stata vista". Se
ogni giorno arriva un'E-Mail con quella tripla restera' nel DB in omnia
saecula saeculorum).


 loro servizi
IMHO: "mail" != "chat"
Enrico

 problemi di SPF,
Non sono proprio d'accordo, dato che SPF garantisce che il mittente 
(envelope address) sia chi dice di essere, mentre DKIM/DomainKeys 
garantiscono anche (soprattutto) che il messaggio che arriva sia 
effettivamente quello mandato.
Ciò non toglie che aiutino anche a validare il dominio del mittente.
-- 
Vide

 effettivamente quello mandato.
A proposito: qualcuno usa DKIm con Postfix?
Avevo scaricato dkimproxy ma non ho ancora avuto il tempo
di gaurdarlo...

 di gaurdarlo...
semi-spam (anche se l'articolo in questione non l'ho scritto io:)
http://anothersysadmin.wordpress.com/2008/01/16/domainkeysdkim-with-postfix/
Critiche/commenti nei commenti, che così arrivano all'autore :)
-- 
Vide

 
c'è una bella differenza tra IMHO e l'utilizzatore finale dove al 90% 
delle volte preferisce l'incomprensibile l'outlook express con IMAP 
rispetto al completo thunderbird... figurati spiegargli di non 
utilizzare le email come chat che significa.
inoltre in alcuni campi di applicazione questa è una normale procedura. 
immagina un helpdesk "rapido" con tempi di risposta celeri...

sto davvero impazzendo...
su una opensuse 10.3
wget 
http://mesh.dl.sourceforge.net/sourceforge/libdbi/libdbi-0.8.3.tar.gz
tar xvfz libdbi-0.8.3.tar.gz
./configure && make && make install
e fin qui.
wget 
http://mimo.gn.apc.org/gps/gps-1.004.tar.gz
tar xvfz gps-1.004.tar.gz
cd gps-1.004
make -f Makefile.cvs
./configure
make
make install
vi /download/gps-1.004/etc/gps.conf
etc etc
esce questo errore...
gps: error while loading shared libraries: libdbi.so.0: cannot open 
shared object file: No such file or directory
le librerie ci sono, ma non le trova... GRRR

Il Tue, 10 Mar 2009 15:46:22 +0100, Vide scrisse:

E' lo stesso che mi ero "bookmarkato" per futura consultazione...:-)

 Ciň non toglie che aiutino anche a validare il dominio del mittente.
Si, a meno che non ci siano di mezzo Mailman, Majordomo e altri software
simili che violentano gli Headers...


 le librerie ci sono, ma non le trova... GRRR
ma le hai nel giusto path?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
"Well, if you can't believe what you read in a comic book, what *___   can*
you believe?!"
		-- Bullwinkle J. Moose [Jay Ward]

 
le ha installate in /usr/local/lib ma ho provato a copiarle in /usr/lib

writethem ha scritto:

ah ecco
cp /usr/local/lib/* /lib64/
risolto

 E' lo stesso che mi ero "bookmarkato" per futura consultazione...:-)
Farò presente :)
-- 
Vide

 cp /usr/local/lib/* /lib64/
Brrrrrrrr...

 Headers
La RFC non è d'accordo
http://www.ietf.org/rfc/rfc4870.txt
-- 
Vide

whiplash ha scritto:

c'erano solo quelle librerie. cmq non funziona richiede dbi-drivers che 
non riesco ad installare sulla opensuse.
sono bloccato e non trovo documentazione.
:wq
  :-(


In realtà non solo è così, ma è anche inevitabile: gli header vengono 
aggiunti nel corso del transito della mail, a completa discrezione degli 
hop intermedi.
Quindi è impossibile firmarli tutti...
-- 
http://bofhskull.wordpress.com/

 Quindi è impossibile firmarli tutti...
Sì appunto, è questo è uno dei punti deboli di DKIM. Però quello che 
contestavo a Luca è il fatto che non si generi l'hash prendendo in 
considerazione anche il corpo del messaggio. 
-- 
Vide

ok ok, ho ripristinato tutto così da non lasciar tracce delle mie cag* 
ehm... fesserie.
postgrey è molto più semplice in OpenSuse.
Se a qualcuno serve:
yast2 --install postgrey
chkconfig postgrey on
vi /etc/sysconfig/postgrey
cambia la direttiva in
POSTGREY_CONN_OPTIONS="--unix=/var/spool/postfix/postgrey/socket 
--inet=
127.0.0.1:10031
 --delay=180 --max-age=15"
vi /etc/postfix/
main.cf
aggiungi alla fine di smtpd_recipient_restrictions
check_policy_service inet:
127.0.0.1:10031
service postgrey restart
service postfix restart
il database si trova in /var/lib/postgrey

>> Vai un po' a vederti COSA e' Greylist... Il ritardo e' SOLO la prima volta.
ho un proxy smtp davanti al server che non posso togliere, ho notato che 
dopo qualche email postgray non entra più in funzione. come posso 
risolvere (preservando il proxy) ?

 risolvere (preservando il proxy) ?
Se tutte le mail sono viste arrivare dall'IP del proxy, buonanotte.
O il greylisting lo fa lui (se può), o t'attacchi...
-- 
http://bofhskull.wordpress.com/

 
Eventualmente va messo in blacklist il proxy.
-- 
"Benvenuto nel mondo vero."
Roy Batty

 Eventualmente va messo in blacklist il proxy.
A parte che mi sfugge il senso di quello che hai scritto, azzardando 
un'interpretazione:
intendi per caso dire di non greylistare il proxy, vanificando del 
tutto il greylisting?

 
ok. questo proxy non fa altro che verificare le email con degli RBL e, 
in caso positivo, aggiungere il tag *SPAM*.
Immagino che la stessa cosa la potrei fare ugualmente sul mailserver, 
quindi il proxy posso spegnerlo e pubblicare la 25 del mailserver 
direttamente.
perň c'č un problema... ehm... come taggo l'oggetto di una email 
entrante al verificarsi di un positivo di una RBL?
Grazie ancora!!!

 il proxy posso spegnerlo e pubblicare la 25 del mailserver direttamente.
Auguri...

 entrante al verificarsi di un positivo di una RBL?
Spamassassin e/o postfix stesso?
Enrico

Neoviruz ha scritto:

pubblicare direttamente non significa sparargli un ip pubblico 
direttamente. un semplice pat, e davanti vi è un UTM. non espongo porte 
tipo ssh.

Enrico Bassetti ha scritto:

immaginavo, ma non ho trovato molti howto in giro, hai qualche spunto di 
riflessione?

 un semplice pat, e davanti vi è un UTM. non espongo porte tipo ssh.
E questo non cambia di una virgola il fatto che una conoscenza poco 
approfondita del mailserver che utilizzi ti espone a parecchi problemi, 
sulla base di quanto letto qui.

Neoviruz ha scritto:

vuoi rispondere a dei quesiti? aprire un flame? dare pillole di 
saggezza? Ne vale davvero la pena intervenire solo per dire questo?
non dovrei mettere mai su un mailserver perchè ho chiesto una info su 
come arginare lo spam? il 90% del mondo linux è "hands on", vi sono 
pochi corsi di certificazione e/o corsi seri, soprattutto su questo 
campo. Non vedo perchè io debba demordere, dare un bel service postfix 
stop e spegnere tutto. Si impara, altrimenti non esisterebbero i forum, 
i ng, i gruppi di supporto...
Sinceramente non mi sento in colpa. :)

 arginare lo spam? 
Non dovresti mettere le mani su un mailserver nel momento in cui 
dimostri di star modificando configurazioni senza sapere esattamente 
quello che fai, vedi implementare il greylisting dietro ad un proxy 
smtp.
Poi ognuno è libero di fare le proprie scelte, come io sono libero di 
dirti che secondo me rischi di avere problemi.
Ti da fastidio?
Problemi tuoi, mettimi nel killfile e vivi tranquillo.

 riflessione?
Spamassassin ha buona documentazione sul suo sito. Comunque vedi anche
il 
master.cf
 di postfix e la relativa doc: non so come funziona il tuo
proxy, ma potresti addirittura inserirlo "insieme", dopo la ricezione e
prima di posizionarlo nella mailbox o altro.
Per il resto, in postfix di solito ci si possono mettere (diciamo è
buona norma se non vuoi spam) le blacklist tipo 
www.spamhaus.org
 (sul
sito ci sono le istruzioni per Postfix e altri MTA) e altre. Per vedere
quali blacklist, in passato in questo NG ci sono state fior di
discussioni sull'argomento ;-)
Enrico

 come arginare lo spam?
La preoccupazione maggiore penso che sia in genere legata agli
open-relay e possibili configurazioni "non proprio utili" ad arginare lo
spam (per tutti, da e verso te)...
Enrico

Enrico Bassetti ha scritto:

in tal caso assicuro che non è un open relay. questo è poco ma certo.

 discussioni sull'argomento ;-)
però a me serve taggare l'oggetto, non segare come fanno ad esempio le 
direttive
reject_rbl_client 
list.dsbl.org
,
reject_rbl_client 
sbl.spamhaus.org
,
reject_rbl_client 
cbl.abuseat.org
,
reject_rbl_client 
dul.dnsbl.sorbs.net
su questo non ho trovato molto purtroppo.

 Problemi tuoi, mettimi nel killfile e vivi tranquillo.
questo non avverrà mai, ogni parere per me è prezioso e tu hai espresso 
un legittimo dubbio.

 tempo, non ho voluto approfondire ma mi sembrava lineare.
Dipende sempre dalla configurazione e dalle N implementazioni che 
esistono.
Ma come faceva notare skull, il greylisting è utile per verificare 
principalmente che l'IP che ti contatta sia effettivamente un 
mailserver, costringendolo a ritentare l'invio, cosa che non sempre i 
bot fanno.
Ed è utile se implementato sul mailserver di frontiera, nel tuo caso il 
proxy, altrimenti ha davvero poco senso.

 di tempo, non ho voluto approfondire ma mi sembrava lineare.
Si, ok.
Ma visto che le mail arrivan tutte dall'IP del proxy significa che una 
volta che una mail da X diretta ad Y ha passato il greylisting, 
*qualsiasi* mail successiva con le stesse caratteristiche passerà, 
indipendentemente dall'IP di origine.
Non solo. Come detto, greylisting serve a "validare" l'IP di emissione, 
verificando sia un mailserver.
Dopo che lo si è verificato una volta, tutte le mail successive 
dovrebbero bypassare il greylisting, altrimenti introduci latenza in 
ogni singola comunicazione, inutilmente.
Se tutto arriva dall'IP del proxy, però, o applichi delay a tutto o non 
lo applichi a nulla se non alla prima mail che passa...
-- 
http://bofhskull.wordpress.com/

 indipendentemente dall'IP di origine.
ah ok, perfetto.
quindi una volta che una tripletta è verificata il whitelist viene 
applicato all'IP e NON alla tripletta. diciamo che greylist "valida" il 
mailserver, non le caselle. giustamente.
ecco spiegato l'arcano :)

 mailserver, non le caselle. giustamente.
Questo se l'algoritmo è applicato con un senso (o almeno quello che IMHO 
è il senso "giusto" dell'algoritmo).
E' comunque pieno di implementazioni che validano la tripletta e non 
l'IP, AFAIK...
-- 
http://bofhskull.wordpress.com/


No, effettivamente stavo confondendo la situazione descritta con un'altra che mi 
era capitata qualche tempo fa, con un mailserver postfix dietro un firewall, e 
passava tutto perche' passando diventava proveniente da quest'ultimo, in quel 
caso era necessario appunto mettere proprio in blacklist il firewall.
Sto andando un po' a memoria...


 Sto andando un po' a memoria...
La vecchiaia fa brutti scherzi ;)

 l'IP, AFAIK...
Postgrey lavora sulla tripletta, hai esperienza di qualche altro 
software che lavora a livello di IP che valga la pena implementare ?
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere...sembra 
facile a prima vista...ma la verità è che non avere nulla da perdere 
significa essere pronti a rischiare tutto ciò che si possiede.

 in tal caso assicuro che non è un open relay. questo è poco ma certo.
Potresti però essere un emettitore di backscatter, ad esempio, a seconda
di come hai configurato il tuo postfix...

 su questo non ho trovato molto purtroppo.
ok, ho implementato spamassassin con una utile direttiva
add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ 
tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_
così da tener sotto controllo i punteggi anche degli ham.
però, se abilito il controllo RBL di spamassassin, come faccio a capire 
*quali* rbl lui usa?

 *quali* rbl lui usa?
Spamassassin da una mano per quanto può, ma non ci baserei l'intera 
struttura di filtraggio, quando i numeri aumentano diventa poco 
scalabile.
Non capisco l'ostinazione a non utilizzare le rbl direttamente in 
reject, usate bene i falsi sono praticamente inesistenti.
Se ci aggiungi il fatto che con spamassassin il rischio di fp è più 
alto, soprattutto se non lo conosci, secondo me stai continuando a 
"mettere il culo nelle pedate".

 reject, usate bene i falsi sono praticamente inesistenti.
in tutta onestà in una settimana ecco i risultati delle rbl:
spamcop 2 fp
sorbs 3 fp
spamhaus 2fp
zen 1 fp
abuseat 1fp
a me andrebbe bene un filtraggio basato su rbl, serio, ma non dev'essere 
in drop ma in subject tag. il rischio è troppo alto.
sto semplicemente trovando un modo e la direttiva reject_rbl_client 
taglia direttamente.
a me basterebbe una
tag_rbl_client subject:***SPAM***
se esistesse...
che fantasia :)

 zen 1 fp
Mi suona molto strano, con numeri ben maggiori dei tuoi, ho avuto un 
paio di casi negli ultimi due anni.
Le stai usando in reject_rbl_client o da spamassassin?

 il rischio è troppo alto.
Il rischio è quasi inesistente.
Ti do qualche numero.
Ho una coppia di server a basso traffico.
In una giornata tipica, ricevo circa 3000 messaggi buoni e ne
respingo circa 10000.
La parte grossa del lavoro la fanno 
zen.spamhaus.org
 e i controlli 
sugli helo; seguono altre blacklist e controlli vari built-in in postfix.
Seguono i milter, clamav e spamassassin: in tutto intercetto non più 
di un centinaio di mail al giorno.
Il greylisting qualcosa ancora fa, ma la sua efficacia è decisamente
diminuita.
Ebben, ti posso assicurare che i reject da blacklist generano un numero
di falsi positivi assolutamente irrilevante (meno di cinque casi in vari
mesi di vita dei presenti server), mentre un paio di falsi positivi 
quotidiani legati a clamav (uso un set esteso di signature) 
e a spamassassin capitano spesso e volentieri (posso, visti i volumi
ancora permettermi, nei ritagli di tempo, di esaminare ciò che
intercettano i milter, con i flag -Q e -B, rispettivamente, di
clamav-milter e spamass-milter).

 software che lavora a livello di IP che valga la pena implementare ?
Io uso storicamente GLD configurato in modalità "MXGREY":
Shall we use the mxgrey algorithm ? (0=No,>0=Yes) (default is 0)
the mxgrey algorithm is a variation of the greylist algorithm.
When this is enabled, we allow all incoming mails from an IP address
whatever source/destination email as long as this IP has been greylisted
at least X time and succeded the mail resend.
Example:
The IP 1.2.3.4 sends an email from 
s...@domain.com
 to 
us...@yourdomain.com
We greylist this mail as this IP is not yet in database and send a 450 
SMTP code
After some time, the IP re-send the mail from 
s...@domain.com
 to 
us...@yourdomain.com
.
We update the db.
Some time after the ip 1.2.3.4 sends an email from 
jo...@domain.com
 to 
fr...@yourdomain.com
We will accept this mail without any greylisting, as this ip already 
succeded a greylist test and thus seems to be a valid smtp server and 
not a spammer .
The advantage of this method, is that it reduce the re-send time due to 
greylisting to x mail per server instead of one mail per destination .
The value you provide in MXGREY is the minimum number of succesful 
greylists before accepting all mails from this MX. higher the number is, 
harder is to get in.
This algortihm replace the old LIGHTGREYDOMAIN which was available prior 
version 1.6
-- 
http://bofhskull.wordpress.com/

 che faccio? *aiuto!!*
Se sei sicuro di ricevere mail SOLO da determinate nazioni,
puoi impostare un filtro geografico su IPTABLES ( Geoip ).
Così fai fuori a monte per es. tutto quello che proviene dalla 
cina,giappone etc .. :-)
					-- Yena --

 puoi impostare un filtro geografico su IPTABLES ( Geoip ).
Perchè mi stupisco ancora di quanta gente cerchi di farsi del male al 
mondo?

 cina,giappone etc .. :-)
purtroppo il server in questione riceve email da tutto il mondo.
in ogni caso ho arginato il problema con greylist+spamassassin. Davvero 
non pensavo di segare 4000 email al giorno di cui circa 3800 con 
greylist (e i controlli intrinsechi di postfix)... eppure ora sono 
libero e felice come un farfallone :P

 Io uso storicamente GLD configurato in modalità "MXGREY":
Grazie mille, provero'
