Newsgroup: it.comp.os.linux.sys
Titolo: postfix, DNSBL/RBL e falsi positivi


La cosa strana č che gli IP dei mittenti non risultano in nessuna 
blacklist!!!
Ecco uno stralcio del main.cf...
[prima]
<...cut...>
smtpd_client_restrictions =
   permit_mynetworks,
   reject_rbl_client 
dnsbl.sorbs.net
smtpd_recipient_restrictions =
   reject_invalid_hostname,
   reject_non_fqdn_sender,
   reject_non_fqdn_recipient,
   reject_unknown_sender_domain,
   reject_unknown_recipient_domain,
   reject_unverified_sender,
   reject_unverified_recipient,
   reject_unauth_pipelining,
   check_recipient_access hash:/etc/postfix/access_recipient,
   check_helo_access hash:/etc/postfix/access_helo,
   check_sender_access hash:/etc/postfix/access_sender,
   check_client_access hash:/etc/postfix/access_client,
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   reject_unlisted_recipient,
   reject_rbl_client 
dnsbl.sorbs.net
,
   reject_rbl_client 
bl.spamcop.net
,
   reject_rbl_client 
sbl.spamhaus.org
,
   reject_rbl_client 
pbl.spamhaus.org
,
   reject_rbl_client 
xbl.spamhaus.org
,
   reject_rbl_client 
cbl.abuseat.org
,
   reject_rbl_client 
list.dsbl.org
,
   permit_mx_backup,
   reject
address_verify_map = btree:/var/spool/postfix/verify/maps
<...cut...>
[da oggi]
<...cut...>
smtpd_recipient_restrictions =
   reject_invalid_hostname,
   reject_non_fqdn_sender,
   reject_non_fqdn_recipient,
   reject_unknown_sender_domain,
   reject_unknown_recipient_domain,
   reject_unauth_pipelining,
   check_recipient_access hash:/etc/postfix/access_recipient,
   check_helo_access hash:/etc/postfix/access_helo,
   check_sender_access hash:/etc/postfix/access_sender,
   check_client_access hash:/etc/postfix/access_client,
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   reject_unlisted_recipient,
   permit_mx_backup,
   reject
<...cut...>
Qualcuno mi da una mano?
Grazie.

 Qualcuno mi da una mano?
Partiamo dalla parte ovvia: a quale DNS si appoggiano i server in questione?

 questione?
Innanzi tutto Grazie, anche per la tempestività.
I server DNSBL configurati in postfix sono:
<...CUT...>
smtpd_client_restrictions =
   permit_mynetworks,
   reject_rbl_client 
dnsbl.sorbs.net
smtpd_recipient_restrictions =
<...CUT...>
   reject_rbl_client 
dnsbl.sorbs.net
,
   reject_rbl_client 
bl.spamcop.net
,
   reject_rbl_client 
sbl.spamhaus.org
,
   reject_rbl_client 
pbl.spamhaus.org
,
   reject_rbl_client 
xbl.spamhaus.org
,
   reject_rbl_client 
cbl.abuseat.org
,
   reject_rbl_client 
list.dsbl.org
,
<...CUT...>
(i tre *.
spamhaus.org
 verranno sostituiti da 
zen.spamhaus.org
)


Non intendo le DNSBL. Intendo proprio i *resolver* DNS che quel server 
utilizza...

Skull ha scritto:

Ops!
contenuto di /etc/resolv.conf:
search domain.tld
nameserver 212.216.172.62
nameserver 212.216.112.112
nameserver 151.99.125.3

 nameserver 151.99.125.3
Boh: da qui tutti e 3 rispondono come atteso, quindi il problema non sta 
nei resolver che usi (ammesso e non concesso che non vi sia 
qualcos'altro a manipolare queste query prima di farle arrivare al 
resolver).
Per sicurezza, prova ad eseguire:
host 
8.169.32.24.sbl.spamhaus.org
 212.216.172.62
host 
8.169.32.24.sbl.spamhaus.org
 212.216.112.112
host 
8.169.32.24.sbl.spamhaus.org
 151.99.125.3
Per tutte e 3, la risposta dovrebbe essere 127.0.0.2.
Se cambi l'8 iniziale in 9, devi ottenere record non esistente.
Altra domanda: negli ultimi giorni hai per caso cambiato qualcosa nei 
mountpoint di quella macchina? In particolare, ci sono -o almeno 
c'erano- noti problemi di risoluzione se il chroot di postfix viene 
piazzato su una partizione noexec (però in quel caso mi aspetterei che 
falliscano tutte le query, non solo alcune, nè dovrebbe tornare valori 
"anomali", ma fallire semplicemente la risoluzione).

 "anomali", ma fallire semplicemente la risoluzione).
No, nessun cambiamento.
In effetti appena abilito una qualsiasi restrizione DNSBL tra quelle 
citate TUTTE le query restituiscono esito negativo, ovvero TUTTE le mail 
vengono segnalate come possibile spam, non solo alcune e non si riceve + 
nulla.

 nulla.
*Assai* strano.
Per curiosità, di che mole di mail parliamo (tipo 50 mail/die? 500? 50000?)

Skull ha scritto:

Si, anch'io per un attimo avevo pensato di aver raggiunto il limite 
gratuito ma non dovrebbe trattarsi di questo.
pflogsum riporta questi valori per maillog.1 (7 day)
    1820   received
    1507   delivered
       0   forwarded
      16   deferred  (26  deferrals)
       0   bounced
   17267   rejected (91%)
       0   reject warnings
       0   held
       0   discarded (0%)

 gratuito ma non dovrebbe trattarsi di questo.
Il "limite gratuito" viene applicato sull'IP del resolver, non sul tuo: 
il gestore della DNSBL non ha alcun modo di sapere chi sta usando il 
resolver.
Quindi o è tutto il DNS di Tin ad assere messo in ACL, oppure non è 
quello il problema.
In virtù del fatto che se interrogo io il DNS di Tin, a me non risponde 
"positivo", dubito che il problema sia quello:
skull@hydra:~$ host 
105.238.57.88.bl.spamcop.net
 212.216.172.62
105.238.57.88.bl.spamcop.net
 does not exist at 
ns1.tin.it
, try again
skull@hydra:~$ host 
105.238.57.88.bl.spamcop.net
 212.216.112.112
105.238.57.88.bl.spamcop.net
 does not exist at 
ns4.tin.it
, try again
skull@hydra:~$ host 
105.238.57.88.bl.spamcop.net
 151.99.125.3
105.238.57.88.bl.spamcop.net
 does not exist at 
dns2.interbusiness.it
, 
try again
Quantomeno, però, dovrebbe farti pensare che tutto sommato affidare le 
risoluzioni DNSBL al resolver dell'ISP non è troppo saggio, dato che è 
assi più probabile che *quel* resolver finisca nelle ACL dei gestori di 
DNSBL, non essendo plausibilmente tu l'unico utente...
Quel che potrebbe invece essere -ma solo potenzialmente- è che a 
pastrugnarti le query e "rispondere sempre positivo" sia lo stesso DNS 
di Tin, per qualche policy loro, ammesso che esista...
Se tu, dal tuo srever, esegui le stesse risoluzioni che ho incollato 
sopra, cosa ottieni?

 try again
Host 
105.238.57.88.bl.spamcop.net
 not found: 3(NXDOMAIN)

 
105.238.57.88.bl.spamcop.net
 has address 212.48.8.140
Se non è un paciugo da copincolla, ho l'impressione che questa sia 
decisamente un problema...

Skull ha scritto:

Già!
No, non è colpa del copincolla :-)
Utilizzando i DNS Interbusiness...
[root@bridge]# host 
28.150.223.84.bl.spamcop.net
 151.99.125.3
Host 
28.150.223.84.bl.spamcop.net
 not found: 3(NXDOMAIN)
...mentre i DNS di Alice...
[root@bridge]# host 
28.150.223.84.bl.spamcop.net
 212.216.112.112
28.150.223.84.bl.spamcop.net
 has address 212.48.8.140
Host 
28.150.223.84.bl.spamcop.net
 not found: 3(NXDOMAIN)
Host 
28.150.223.84.bl.spamcop.net
 not found: 3(NXDOMAIN)
...sembra che rispondino due volte(?!), prima con 212.48.8.140 (ip di 
una società collegata a Telecom, vedi whois 212.48.8.140, quindi google 
Matrix spa), poi "picche" come in effetti dovrebbe essere.
Giusto?
No va, no va propio bbuono!
Che i DNS di Alice inoltrino tutte le query anche a questa società?
Comunque sia io inizio ad utilizzare i DNS di Interbusiness e vediamo 
che succede.

Skull ha scritto:

In che ordine pensi sia meglio meterli?
nameserver 151.99.125.1
nameserver 151.99.125.2
nameserver 151.99.125.3
nameserver 151.99.0.100

 
In nessun ordine, tira in piedi un dns locale.

 che succede.
Io metterei in piedi un DNS a parte...

Luca Curatola aka Neoviruz ha scritto:

Certo, per il momento ho modificato il resolv.conf ma la fine sarà quella!
Ciao a tutti e grazie.

Una interessante lettura l'ho scritta oggi :
 
http://www.dreamsnet.it/2013/11/come-implementare-e-configurare-correttamente-le-dnsbl-o-rbl-sul-nostro-server-di-posta-onde-evitare-falsi-positivi/
 
 


Se sei perennemente nelle liste antispam non devi convincere gli altri che è 
bene che loro le usino nel modo sbagliato ma sei tu che devi chiederti cosa 
sbagli.
Quindi, nel tuo scritto, parti da assunti sbagliati o obsoleti per 
raggiungere conclusioni balzane, inutili e scorrette.
 
In sintesi: 
Tecnologie di 5 anni fa, best practice ignorate, non conoscenza delle RBL e 
di come funzionano, assunzioni autoritarie senza alcun fondamento.
 
IMHO Inutile.
 


Tristemente concordo :-(
 

SPAM e dunque consegnata.
 
Quindi che deve fare una email per essere taggata come spam?
 
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu