Newsgroup: it.comp.os.linux.sys
Titolo: Postfix e blacklist

Leggendo questo:
http://www.akadia.com/services/postfix_uce.html
ho raggruppato tutti i check delle rbl che facevo in smtpd_client_restrictions 
dentro a smtpd_recipient_restrictions.
Il problema è che ora le blacklist non sembrano più venir matchate, mi passa di 
tutto :(
Come mai ?
L'smtpd_recipient_restrictions è così ora:
smtpd_recipient_restriction = check_client_access hash:/etc/postfix/client,
         check_sender_access hash:/etc/postfix/sender,
         permit_mynetworks,
         reject_non_fqdn_recipient,
         reject_unknown_recipient_domain,
         reject_unauth_pipelining,
         reject_unauth_destination,
         reject_unauth_destination,
         reject_invalid_hostname,
         reject_non_fqdn_hostname,
         reject_non_fqdn_recipient,
         reject_unknown_recipient_domain,
         reject_unauth_pipelining,
         reject_rbl_client 
bl.spamcop.net
,
         reject_rbl_client 
blackholes.easynet.nl
,
         reject_rbl_client 
zen.spamhaus.org
,
         reject_rbl_client 
dnsbl.njabl.org
,
         reject_rbl_client 
cbl.abuseat.org
,
         reject_rbl_client 
dnsbl.ahbl.org
,
         reject_rbl_client 
virbl.dnsbl.bit.nl
,
         reject_rbl_client 
combined.njabl.org
,
         reject_rbl_client 
bhnc.njabl.org
,
         reject_rbl_client 
dul.dnsbl.sorbs.net
,
         reject_rbl_client 
list.bbfh.org
,
         permit
cosa c'è di sbagliato ?
Grazie
Rizio

 smtpd_recipient_restriction = check_client_access hash:/etc/postfix/client,
                            ^^^^
Mh... manca una "s"? :-)
bye G.L.
-- 
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità analogica.

 bye G.L.
Grazie mille,
Rizio

 Grazie mille,
De nada.


 Però mi confermi che le altre logiche sono corrette giusto ?
Un setup così è ottimo se non vuoi ricevere mail.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 Un setup così è ottimo se non vuoi ricevere mail.
In effetti... non me ne voglia l'OP, ma pur non essendo un espertone
(non gestisco mail server con grossi volumi di posta, tutt'altro)
alcune opzioni e alcune blacklist farebbero pensare: massi', gettiamo
el mucchio, male non fara'. :-)


 Un setup così è ottimo se non vuoi ricevere mail.
Beh, se non fosse che in ditta mi pagano per riceverle potrebbe non essere un 
problema ;)
Perchè dici così ? Sono i vari "reject unauth*" a cui ti riferisci o le blacklist ?
Perchè riguardo ad alcune bl ho già ripulito un pò perchè erano troppo restrittive.
Rizio

 bye G.L.
Rizio

 THe_ZiPMaN ha scritto:


Dunque, per quanto riguarda le dnsbl, ne metto poche:
     reject_rbl_client 
zen.spamhaus.org
,
     reject_rbl_client 
b.barracudacentral.org
,
     reject_rbl_client 
bl.spamcop.net
,
     reject_rbl_client 
combined.njabl.org
,
     reject_rbl_client 
dul.dnsbl.sorbs.net
,
(ok, ci sara' chi critichera' l'uso di barracuda ma. per il momento,
e considerato il basso traffico, non mi ha dato noie, e c'e' da
parecchio. Le ultime tre liste non intevengono quasi mai)
il resto lo faccio fare da spamassassin (togliendo naturalmente
dalla configurazione i check su liste presenti fra quelle sopra),
che si limita a contrassegnare le email "sospette".
Io ho, per cio' che riguarda gli hard reject 5xx:
     reject_invalid_helo_hostname,
     reject_non_fqdn_helo_hostname,
     reject_non_fqdn_sender,
     reject_non_fqdn_recipient,
     reject_unauth_destination,
     [qui in mezzo stanno le dnsbl/rbl)
e i soft reject 4xx:
     reject_unknown_sender_domain,
     reject_unknown_recipient_domain,
     reject_unknown_reverse_client_hostname,
---
Vediamo le tue configurazioni:
reject_unauth_pipelining: io veramente me lo ritrovo in
smtpd_data_restrictions, e suppongo che la' debba essere...
Differente rispetto al tuo e' che, un po' piu' restrittivamente,
preferisco anche mandare a cagare chi non ha un record PTR
(reject_unknown_reverse_client_hostname).
Poi, come hai visto, preferisco mettere i soft reject alla
fine, perche' se me ne becca uno prima di un hard reject
(fra cui sono comprese le dnsbl/rbl) che eventualmente avrebbe
"matchato", il client potrebbe continuare a rompere "bussando"
per giorni... (eccezion fatta per i mailer di massa del ca**o,
che in genere non ritentano in caso di soft reject).
Per le dnsbl/rbl, devi anche cercare di ordinarle facendo
delle statistiche, e ordinarle da quella che matcha di piu'
a quella che matcha di meno.
Poi ovviamente mica si puo' avere la ricetta valida per tutti: :-)
a me va bene (con un po' di blacklist e whitelist personalizzate).


 parecchio. Le ultime tre liste non intevengono quasi mai)
Io in realtà eliminerei SORBS, più che altro...
-- 
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/

 bye G.L.
Rizio

 blacklist o al modo con cui è configurato.
bl... poi c'era qualcos'altro di minore che non ricordo (e non vedo più
il msg originale)


 più indicata in scoring.
Agree, ma c'è di più... :-P
SORBS DUHL, allo stato attuale delle cose, lista quello che lista PBL di
spamhaus (qui interrogata via ZEN), e più della stessa ha i FP.
Ma soprattutto, SORBS è stata acquisita da GFI, ma so per certo che
Michelle è in cerca di nuovo lavoro (sicchè non lavora più lì) e nessuno
di mia conoscenza al momento sa se la testa di SORBS[1] al momento sia
con Michelle o sia rimasta in GFI. Per quanto mi riguarda SORBS è
end-of-life da almeno 4 anni....
(in termini di upgrade del ruleset, si può tranquillamente considerare
l'aggiunta di DBL in fase envelope; qualche hint su
http://bofhskull.wordpress.com/2010/03/01/sempre-su-dbl/
)
[1] se mai ve ne è stata una


 il msg originale)
Il resto era questo:
         reject_non_fqdn_recipient,
         reject_unknown_recipient_domain,
         reject_unauth_pipelining,
         reject_unauth_destination,
         reject_unauth_destination,
         reject_invalid_hostname,
         reject_non_fqdn_hostname,
         reject_non_fqdn_recipient,
         reject_unknown_recipient_domain,
         reject_unauth_pipelining,
Intanto, come sempre, grazie dei suggerimenti
Rizio

          reject_unauth_pipelining,
Ti conviene rileggerlo bene, secondo me.
Ho idea che le cose tu le abbia aggiunte un pò a casaccio, senza pensarci 
troppo.
Altrimenti non ci sarebbero quei duplicati sparsi ovunque.

 Altrimenti non ci sarebbero quei duplicati sparsi ovunque.
Perchè, nel caso volesse avere una sicurezza maggiore non può metterli
doppi o tripli ?



Non è che se metti la stessa linea 100 volte aumenti la sicurezza.
Passi per due linee contigue uguali che alla fine, sostanzialmente, 
incidono poco.
Ma se metti reject_non_fqdn_recipient sia alla fine che all'inizio del 
"ruleset" i casi sono due:
- non sai cosa stai facendo
- se lo sai, c'è il 50% delle probabilità che lo stai facendo sbagliato 
(perchè una delle due posizioni non è quella dove volevi mettere la 
regola).

 Altrimenti non ci sarebbero quei duplicati sparsi ovunque.
E' stato un errore di copia incolla dal primo post che mi stò portando dietro 
per tutto il thread
Rizio

 Io in realtï¿œ eliminerei SORBS, piï¿œ che altro...
Fatto. Tanto, non matchava nulla, dopo le prime tre dnsbl. :-)
Cosa ne penseresti del fatto che gli ho appena messo fail2ban,
che banna su postfix e reject 554, 504, 501? (in realta' l'ho
messo dapprima perche' mi ero scocciato dei "martoriamenti"
via dizionario su pop3, ma notando che fra le varie c'era
anche postfix...).
bye G.L.
-- 
Da i.d.c.tutela:
P.S. Quando ci sarï¿œ lo switch-off, avrï¿œ problemi anche col
monitor del PC? Ho visto che ï¿œ collegato in modalitï¿œ analogica.

 anche postfix...).
Che dipende tanto da dove e come lo applichi.
Io lo uso tipicamente sugli MSA, a segar fuori tentativi di bruteforce
su SMTP-AUTH, ma anche cosï¿œ ï¿œ da starci attenti.
Su MTA in ricezione me ne guarderei, e userei piuttosto approcci piï¿œ
controllabili, a livello SMTP...
