SpamAssassin e URIBL...

[Marco Gaiarin]

Ho seguito con estrema attenzione la discussione che c'è stata qui a seguito
dell'ultimo spamrun. I miei ringraziamenti in particolare a Skull per quanto
fa!

Sono su debian wheezy, quindi SA 3.3.2-5+deb7u2 .

Non conoscevo DBL, ma (pensavo, perlomeno) di usare da tempo delle URIBL nel
mio SpamAssassin, in particolare la mia configurazione era:

skip_rbl_checks 1 # Perchè lo faccio a livello di SMTP, exim

#skip_uribl_checks 0 # è il default

score URIBL_BLACK 3 # Queste derivano da una chiaccherata con MdI
score URIBL_RED 0
score URIBL_JP_SURBL 3
score URIBL_AB_SURBL 3
score URIBL_OB_SURBL 3
score URIBL_WS_SURBL 3
score URIBL_SBL 3

e a cui ho aggiunto, per l'intanto:

score URIBL_DBL_SPAM 3


A quel punto mi sono messo a ''guardare'' i log, ma non ''beccavo'' nulla
con 'DBL'; guardando meglio, ho visto che non ho mai (ultime 4 settimane)
''beccato'' nulla con ''URIBL''. Direi molto strano...


Ho verificato con 'spamassassin -D --lint' e il modulo sembra essere
caricato senza errori (in particolare, non vedo segnalazioni di mancanza di
moduli perl).
Ho provato a commentare (ergo, =0) skip_rbl_checks, ma non è cambiato nulla
comunque.


Dove sbaglio? Grazie.

--
Alla fiera dell'est, per due soldi
un topolino mio padre compro` (A. Branduardi)

[writethem]

Il 27/01/2015 17.41, Marco Gaiarin ha scritto:
>
> Ho seguito con estrema attenzione la discussione che c'è stata qui a seguito
> dell'ultimo spamrun. I miei ringraziamenti in particolare a Skull per quanto
> fa!

> A quel punto mi sono messo a ''guardare'' i log, ma non ''beccavo'' nulla
> con 'DBL'; guardando meglio, ho visto che non ho mai (ultime 4 settimane)
> ''beccato'' nulla con ''URIBL''. Direi molto strano...
>

io ho aggiornato tutti i mailserver con quelle configurazioni, e questo
è l'esito di un mailserver più soggetto a spam (vuoi perchè ha molte
caselle, vuoi perchè ha contatti con diverse nazioni, etc..)

cat /var/log/mail.info | grep "reject" | grep "xbl" | wc -l
47
cat /var/log/mail.info | grep "reject" | grep "dbl" | wc -l
5
cat /var/log/mail.info | grep "reject" | grep "sbl" | wc -l
0

Ovviamente prendi questi numeri con beneficio d'inventario, i log sono
stati ruotati da poco.



Per la cronaca, in fase di envelope, postfix è stato settato così
(relativamente alle dbl di spamhaus):

reject_rbl_client xbl.spamhaus.org=127.0.0.[4;5]
reject_rhsbl_client dbl.spamhaus.org=127.0.1.[2..99]
reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99]
reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99]
reject_rbl_client sbl.spamhaus.org=127.0.0.3

e spamassassin così:

if can(Mail::SpamAssassin::Plugin::URIDNSBL::has_tflags_domains_only)
#URIBL_DBL_SPAM
urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A 127.0.1.10[2-6]
body URIBL_DBL_SPAM eval:check_uridnsbl('URIBL_DBL_SPAM')
describe URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist
tflags URIBL_DBL_SPAM net domains_only
score URIBL_DBL_SPAM 6
endif #URIBL_DBL_SPAM

quindi
cat /var/log/mail.info | grep "reject" | grep "URIBL_DBL_SPAM" | wc -l
0




Considerazioni:

non vedo blocchi sbl, però c'è da dire che il reject dovrebbe essere
FIFO, quindi semplicemente magari le xbl rifiutano la maggior parte
della roba, le dbl il resto e a sbl non rimane nulla... magari mettendo
in testa sbl i log restituirebbero altre statistiche.
Mentre in fase di analisi non becco nulla, ma del resto probabilmente
vale il discorso di prima, l'sbl fa già il suo lavoro con postfix (che è
anche meglio, visto che l'email nemmeno entra).



PS: per lo spam da libero, non sottovalutare questa custom rules
(perfettamente funzionante così come skull l'ha postata), per me è stata
una salvezza, almeno per questa ondata e per questo momento:

header CUSTOM_OGGETTO01 Subject =~ /\d\d?\/\d\d?\/2015 \d\d?:\d\d:\d\d AM/i
score CUSTOM_OGGETTO01 100.0
header CUSTOM_OGGETTO02 Subject =~ /\d\d?\/\d\d?\/2015 \d\d?:\d\d:\d\d PM/i
score CUSTOM_OGGETTO02 100.0

[Skull]

On 28/01/15 11:00, writethem wrote:

> e spamassassin così:
>
> if can(Mail::SpamAssassin::Plugin::URIDNSBL::has_tflags_domains_only)
> #URIBL_DBL_SPAM
> urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A 127.0.1.10[2-6]

Ammetto di non essere espertissimo di spamassassin, ma temo che
urirhssub non prenda quella scrittura in cui il record A viene indicato
con una regexp, che è invece scrittura propria di check_rbl.

https://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.html

> Considerazioni:
>
> non vedo blocchi sbl, però c'è da dire che il reject dovrebbe essere
> FIFO, quindi semplicemente magari le xbl rifiutano la maggior parte
> della roba, le dbl il resto e a sbl non rimane nulla... magari mettendo
> in testa sbl i log restituirebbero altre statistiche.

Ni. Sbl con return code 127.0.0.3 si prende cura di specifiche tipologie
di spam (vedi link in risposta precedente), ma non è detto che tu sia
soggetto a riceverne...

> PS: per lo spam da libero, non sottovalutare questa custom rules
> (perfettamente funzionante così come skull l'ha postata), per me è stata
> una salvezza, almeno per questa ondata e per questo momento:
>
> header CUSTOM_OGGETTO01 Subject =~ /\d\d?\/\d\d?\/2015 \d\d?:\d\d:\d\d AM/i
> score CUSTOM_OGGETTO01 100.0
> header CUSTOM_OGGETTO02 Subject =~ /\d\d?\/\d\d?\/2015 \d\d?:\d\d:\d\d PM/i
> score CUSTOM_OGGETTO02 100.0

FTR, potevi facilmente condensare in una unica REGEXP:

header CUSTOM_OGGETTO01 Subject =~ /\d\d?\/\d\d?\/2015 \d\d?:\d\d:\d\d

[AP]M/i

[writethem]

>> if can(Mail::SpamAssassin::Plugin::URIDNSBL::has_tflags_domains_only)
>> #URIBL_DBL_SPAM
>> urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A 127.0.1.10[2-6]
>
>
> Ammetto di non essere espertissimo di spamassassin, ma temo che
> urirhssub non prenda quella scrittura in cui il record A viene indicato
> con una regexp, che è invece scrittura propria di check_rbl.
>
> https://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.html

cavolo, vero:

Jan 28 11:28:08 *** spamd[6877]: config: SpamAssassin failed to parse
line, "URIBL_DBL_SPAM dbl.spamhaus.org. A 127.0.1.10[2-6]" is not valid
for "urirhssub", skipping: urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A
127.0.1.10[2-6]


ho corretto con

if can(Mail::SpamAssassin::Plugin::URIDNSBL::has_tflags_domains_only)
#URIBL_DBL_SPAM

tflags URIBL_DBL_SPAM_1 net domains_only
urirhssub URIBL_DBL_SPAM_2 dbl.spamhaus.org. A 127.0.1.102
body URIBL_DBL_SPAM_2 eval:check_uridnsbl('URIBL_DBL_SPAM_2')
describe URIBL_DBL_SPAM_2 Contains an URL listed in the DBL
blocklist 2
tflags URIBL_DBL_SPAM_2 net domains_only
score URIBL_DBL_SPAM_2 6
urirhssub URIBL_DBL_SPAM_3 dbl.spamhaus.org. A 127.0.1.103
body URIBL_DBL_SPAM_3 eval:check_uridnsbl('URIBL_DBL_SPAM_3')
describe URIBL_DBL_SPAM_3 Contains an URL listed in the DBL
blocklist 3
tflags URIBL_DBL_SPAM_3 net domains_only
score URIBL_DBL_SPAM_3 6
urirhssub URIBL_DBL_SPAM_4 dbl.spamhaus.org. A 127.0.1.104
body URIBL_DBL_SPAM_4 eval:check_uridnsbl('URIBL_DBL_SPAM_4')
describe URIBL_DBL_SPAM_4 Contains an URL listed in the DBL
blocklist 4
tflags URIBL_DBL_SPAM_4 net domains_only
score URIBL_DBL_SPAM_4 6
urirhssub URIBL_DBL_SPAM_5 dbl.spamhaus.org. A 127.0.1.105
body URIBL_DBL_SPAM_5 eval:check_uridnsbl('URIBL_DBL_SPAM_5')
describe URIBL_DBL_SPAM_5 Contains an URL listed in the DBL
blocklist 5
tflags URIBL_DBL_SPAM_5 net domains_only
score URIBL_DBL_SPAM_5 6
urirhssub URIBL_DBL_SPAM_6 dbl.spamhaus.org. A 127.0.1.106
body URIBL_DBL_SPAM_6 eval:check_uridnsbl('URIBL_DBL_SPAM_6')
describe URIBL_DBL_SPAM_6 Contains an URL listed in the DBL
blocklist 6
tflags URIBL_DBL_SPAM_6 net domains_only
score URIBL_DBL_SPAM_6 6
endif #URIBL_DBL_SPAM



anche se francamente immagino si possa fare meglio di fare 5 query. Però
onestamente non ho capito la logica che riporta nell'esempio il wiki:

urirhssub URIBL_RHSBL_4 rhsbl.example.org. A 127.0.0.4
urirhssub URIBL_RHSBL_8 rhsbl.example.org. A 8


Nel mio cado diventerebbe

tflags URIBL_DBL_SPAM net domains_only
urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A 127.0.1.102
urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A 8

body URIBL_DBL_SPAM eval:check_uridnsbl('URIBL_DBL_SPAM')

describe URIBL_DBL_SPAM_2 Contains an URL listed in the DBL
blocklist

??
mi sfugge onestamente.

>
> FTR, potevi facilmente condensare in una unica REGEXP:
> header CUSTOM_OGGETTO01 Subject =~ /\d\d?\/\d\d?\/2015 \d\d?:\d\d:\d\d
> [AP]M/i

vero, ci avevo pensato ma alla fine avevo fatto tutti i test con due
regole e per pigrizia ho lasciato così :)

[writethem]

> anche se francamente immagino si possa fare meglio di fare 5 query. Però
> onestamente non ho capito la logica che riporta nell'esempio il wiki:
>
> urirhssub URIBL_RHSBL_4 rhsbl.example.org. A 127.0.0.4
> urirhssub URIBL_RHSBL_8 rhsbl.example.org. A 8
>
>
> Nel mio cado diventerebbe
>
> tflags URIBL_DBL_SPAM net domains_only
> urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A 127.0.1.102
> urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A 8
> body URIBL_DBL_SPAM eval:check_uridnsbl('URIBL_DBL_SPAM')
> describe URIBL_DBL_SPAM_2 Contains an URL listed in the DBL
> blocklist

ah no, ok, l'avevo erroneamente intesa come una wildcard. boh, le lascio
tutte e 5 e pace, tanto non arrivo di sicuro alle 100.000 query/giorno a
cui fa riferimento la licenza, sto anni luce sotto. Poi del resto non
sono nemmeno sicuro lui faccia davvero 5 query, teoricamente se
spamassassin fa delle query dns pure, dovrei avere in cache il
risultato. o mi sbaglio?


La cosa bizzarra è che, pur spulciando in lungo ed in largo tutte le faq
delle dbl di spamhaus, non ho trovato come testare solo il range
102-106. dbltest.com restituirà sempre e comunque 127.0.1.2. Alla
peggio, alla prima email contenente quel link, me lo segno per fare i test.

[Skull]

On 29/01/15 08:41, writethem wrote:
>
>> anche se francamente immagino si possa fare meglio di fare 5 query. Però
>> onestamente non ho capito la logica che riporta nell'esempio il wiki:
>>
>> urirhssub URIBL_RHSBL_4 rhsbl.example.org. A 127.0.0.4
>> urirhssub URIBL_RHSBL_8 rhsbl.example.org. A 8
>>
>>
>> Nel mio cado diventerebbe
>>
>> tflags URIBL_DBL_SPAM net domains_only
>> urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A 127.0.1.102
>> urirhssub URIBL_DBL_SPAM dbl.spamhaus.org. A 8
>> body URIBL_DBL_SPAM eval:check_uridnsbl('URIBL_DBL_SPAM')
>> describe URIBL_DBL_SPAM_2 Contains an URL listed in the DBL
>> blocklist
>
> ah no, ok, l'avevo erroneamente intesa come una wildcard.

Sì, non ho mai capito nemmeno io che dovrebbe significare quella
scrittura. Sarebbe da sperimentare, o guardare il codice.

> boh, le lascio
> tutte e 5 e pace, tanto non arrivo di sicuro alle 100.000 query/giorno a
> cui fa riferimento la licenza, sto anni luce sotto. Poi del resto non
> sono nemmeno sicuro lui faccia davvero 5 query, teoricamente se
> spamassassin fa delle query dns pure, dovrei avere in cache il
> risultato. o mi sbaglio?

Confermo cache.

> La cosa bizzarra è che, pur spulciando in lungo ed in largo tutte le faq
> delle dbl di spamhaus, non ho trovato come testare solo il range
> 102-106. dbltest.com restituirà sempre e comunque 127.0.1.2. Alla
> peggio, alla prima email contenente quel link, me lo segno per fare i test.

Temo di non seguirti...

[writethem]

>> La cosa bizzarra è che, pur spulciando in lungo ed in largo tutte le faq
>> delle dbl di spamhaus, non ho trovato come testare solo il range
>> 102-106. dbltest.com restituirà sempre e comunque 127.0.1.2. Alla
>> peggio, alla prima email contenente quel link, me lo segno per fare i test.
>
> Temo di non seguirti...
>

mi ero posto il problema di testare delle singole sottocategorie
specifiche (ad esempio 127.0.1.104), ma mi sembra sia solo possibile
fare la query di test per l'esito generico 127.0.1.2.

Questo perchè la 127.0.1.2 la rifiuto da postfix, ma le 102-106 da
spamassassin in fase di analisi (quindi volevo vedere se funzionassero
solo queste chiamate in causa in questa fase).

[Skull]

On 29/01/15 11:43, writethem wrote:
>
>>> La cosa bizzarra è che, pur spulciando in lungo ed in largo tutte le faq
>>> delle dbl di spamhaus, non ho trovato come testare solo il range
>>> 102-106. dbltest.com restituirà sempre e comunque 127.0.1.2. Alla
>>> peggio, alla prima email contenente quel link, me lo segno per fare i
>>> test.
>>
>> Temo di non seguirti...
>>
>
> mi ero posto il problema di testare delle singole sottocategorie
> specifiche (ad esempio 127.0.1.104), ma mi sembra sia solo possibile
> fare la query di test per l'esito generico 127.0.1.2.

Con "query di test" ti riferisci a test.dbl.spamhaus.org ?

> Questo perchè la 127.0.1.2 la rifiuto da postfix, ma le 102-106 da
> spamassassin in fase di analisi (quindi volevo vedere se funzionassero
> solo queste chiamate in causa in questa fase).

la query è sempre e comunque per un dominio. Come

bofhland.org.dbl.spamhaus.org

per dire:

$ dig +noall +comments +answ a bofhland.org.dbl.spamhaus.org.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54899
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0



O, volendo usare una query che è supposta tornare sempre "listed":


$ dig +noall +comments +answ a test.dbl.spamhaus.org.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22968
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; ANSWER SECTION:
test.dbl.spamhaus.org. 60 IN A 127.0.1.2



Indipendentemente dal fatto che tu sia interessato ai record "cattivi"
(127.0.1.x con 1<x<99) o a quelli "semplicemente abusati" (con x>100),
la query che esegui è sempre la stessa.

E' poi il tuo lato a prendere decisioni diverse a seconda del
(eventuale) A record ottenuto in risposta.


Oppure non capisco la domanda (il che è abbastanza plausibile...)

[writethem]

> Con "query di test" ti riferisci a test.dbl.spamhaus.org ?

si esatto, che per la dbl la FAQ indica dbltest.dbl.spamhaus.org e mi
restituisce 127.0.1.2

> Indipendentemente dal fatto che tu sia interessato ai record "cattivi"
> (127.0.1.x con 1<x<99) o a quelli "semplicemente abusati" (con x>100),
> la query che esegui è sempre la stessa.
>
> E' poi il tuo lato a prendere decisioni diverse a seconda del
> (eventuale) A record ottenuto in risposta.

certo.

immagina però di avere due interrogazioni, uno subito da postfix con il
range 2-6, e uno successivamente da spamassassin con il range 102-106.

Succederà che qualcosa verrà rifiutata subito, e qualcosa dopo,
analizzando il contenuto dell'email come per prassi di spamassassin.


detto questo, io utilizzo un metodo per vedere se le rbl dentro
*spamassassin* funzionano: mando in pasto a spamc una bella email di
spam (con tutto il possibile):

spamc -y -d 127.0.0.1 -p 783 < /tmp/spam.eml

e spamc mi risponde con i controlli che trova. All'interno dell'email
ho, tra le altre cose, un bel link http://dbltest.dbl.spamhaus.org e lui
non mi da nulla di dbl, perchè la query con esito 127.0.1.2 io non la
controllo da spamassassin (che ha il range 102-106), ma solo da postfix
nella fase antecedente.


ad ogni modo non è importante, ed ho risolto: ho preso i domini
contenuti nella prima email beccata dai controlli 102-106 e l'ho
aggiunto all'email di "test" che do in pasto a spamc per vedere se
funziona tutto, ed ora testo le dbl anche in quelle sottocategorie. e
pace. :)

[Marco Gaiarin]

Mandi! writethem
In chel di` si favelave...

> non vedo blocchi sbl, però c'è da dire che il reject dovrebbe essere
> FIFO, quindi semplicemente magari le xbl rifiutano la maggior parte

Si, vero che sono FIFO; ma se non ho capito bene postfix (e gli altri MTA)
fanno un controllo ''secco'' sull'IP del chiamante, mentre SA si permette di
analizzare gli header e fare il controllo anche sui vari hop.

Quindi in teoria dovrebbe/potrebbe alzare lo score di spamness di un
messaggio transitato per smtp leciti ma proveniente d uno non lecito.

> Mentre in fase di analisi non becco nulla, ma del resto probabilmente
> vale il discorso di prima, l'sbl fa già il suo lavoro con postfix (che è
> anche meglio, visto che l'email nemmeno entra).

...le regole sugli URI mi paiono estremamente più ''ricche'' si quelle sugli
IP chiamanti, quindi, scusa, ma questa cosa non riesco a farmela passare
così...


Oggi ho abilitato tutto:

#skip_rbl_checks 1

score URIBL_BLACK 3

score URIBL_RED 0
score URIBL_JP_SURBL 3
score URIBL_AB_SURBL 3
score URIBL_OB_SURBL 3
score URIBL_WS_SURBL 3
score URIBL_SBL 3

score URIBL_DBL_SPAM 3
score URIBL_DBL_PHISH 3
score URIBL_DBL_MALWARE 3
score URIBL_DBL_BOTNETCC 3
score URIBL_DBL_ABUSE_SPAM 3
score URIBL_DBL_ABUSE_REDIR 3
score URIBL_DBL_ABUSE_PHISH 3
score URIBL_DBL_ABUSE_MALW 3
score URIBL_DBL_ABUSE_BOTCC 3

e non ho uno solo score che contenga una URIBL_* ...


Mah...

--
Ragazzi, lavoriamo per il Signore:
la paga non è un granchè, ma la pensione è roba dell'altro Mondo!!!
(letta su una maglietta, da Stefy)

[writethem]

> Quindi in teoria dovrebbe/potrebbe alzare lo score di spamness di un
> messaggio transitato per smtp leciti ma proveniente d uno non lecito.

postfix fa un reject o un accept, non interviene sullo score

>> Mentre in fase di analisi non becco nulla, ma del resto probabilmente
>> vale il discorso di prima, l'sbl fa già il suo lavoro con postfix (che è
>> anche meglio, visto che l'email nemmeno entra).
>
> ...le regole sugli URI mi paiono estremamente più ''ricche'' si quelle sugli
> IP chiamanti, quindi, scusa, ma questa cosa non riesco a farmela passare
> così...
>

da quando ho modificato, queste sono le mie stat (anche qui log appena
ruotati), magari ti torna utile.

postfix:
xbl.spamhaus.com: 30 - dbl.spamhaus.com [2]: 2 - sbl.spamhaus.com: 0

Mail bloccate dalle RBL in fase di analisi (spamassassin):
URIBL_DBL_SPAM dbl Spamhaus: Generico 3 - abused legit spam 0 -
abused spammed redir domain 2 - ab.l. phisg 0 - ab.l.malware 0 -
ab.l. botnet 6
URIBL_SBL 0 - RCVD_IN_ZEN 21 - URIBL_JP_SURBL 15 - URIBL_AB_SURBL
1 - URIBL_OB_SURBL 1 - URIBL_PH_SURBL 1 - URIBL_WS_SURBL 3 -
URIBL_SC_SURBL 1

>
> Oggi ho abilitato tutto:
>
> #skip_rbl_checks 1

perchè?

leggo:
skip_rbl_checks ( 0 | 1 ) (default: 0)
Turning on the skip_rbl_checks setting will disable the DNSEval plugin,
which implements Real-time Block List (or: Blackhole List) (RBL) lookups.

>
> score URIBL_BLACK 3
> score URIBL_RED 0
> score URIBL_JP_SURBL 3
> score URIBL_AB_SURBL 3
> score URIBL_OB_SURBL 3
> score URIBL_WS_SURBL 3
> score URIBL_SBL 3
>
> score URIBL_DBL_SPAM 3
> score URIBL_DBL_PHISH 3
> score URIBL_DBL_MALWARE 3
> score URIBL_DBL_BOTNETCC 3
> score URIBL_DBL_ABUSE_SPAM 3
> score URIBL_DBL_ABUSE_REDIR 3
> score URIBL_DBL_ABUSE_PHISH 3
> score URIBL_DBL_ABUSE_MALW 3
> score URIBL_DBL_ABUSE_BOTCC 3
>
> e non ho uno solo score che contenga una URIBL_* ...

che query hai messo? non vorrei tu abbia copiato dal mio messaggio
precedente. come giustamente diceva skull, l'espressione [2-6] non viene
letta da spamassassin, vanno fatte righe separate 127.0.1.102, 103, 104 etc.

[Skull]

On 29/01/15 16:43, Marco Gaiarin wrote:

> Si, vero che sono FIFO; ma se non ho capito bene postfix (e gli altri MTA)
> fanno un controllo ''secco'' sull'IP del chiamante, mentre SA si permette di
> analizzare gli header e fare il controllo anche sui vari hop.
>
> Quindi in teoria dovrebbe/potrebbe alzare lo score di spamness di un
> messaggio transitato per smtp leciti ma proveniente d uno non lecito.

E' chiamato "deep header parsing", per la cronaca.
Ha alcuni caveat, perchè non tutte le dnsbl sono adatte a questo genere
di utilizzo.

In particolare, PBL (e, in generale, le "derivate dynablock") non ha
senso in questo contesto, mentre XBL ha senso applicarla quando lo
stesso IP non è al tempo stesso anche in PBL (o, almeno, ha senso
abbassare lo score associato a XBL se l'IP è anche in PBL)[1].


L'approccio è utile particolarmente per casi come quelli di cui al
thread precedente: botnet che inietta attraverso relay leciti; si cerca
di matchare ragionevolmente bene caratteristiche del body o degli
header, e si associa (META) la regola risultante con la condizione che
l'IP di iniezione sia -ad esempio- in XBL (è pur sempre un bot...).

Se usato con le dovute cautele, è un approccio estremamente utile,
particolarmente se si ha accesso a dati "raffinati". Tipo: non solo si
sa che l'IP ospita un bot, ma si sa anche quale tipologia di bot, in
modo da limitarne l'applicazione a bot che siano noti per sfruttare
SMTP-AUTH abusati (cutwail in primis).



[1] Ovviamente mi riferisco solamente al caso in cui l'IP in questione
*non* sia last-hop; ma se postfix applica già sia XBL che PBL il
problema non si pone, in teoria...

[Marco Gaiarin]

> Quindi in teoria dovrebbe/potrebbe alzare lo score di spamness di un
> messaggio transitato per smtp leciti ma proveniente d uno non lecito.

Ahem, ovviamente indendevo il duale, proveniente da SMTP leciti ma
transitato per serve non leciti.


> Mah...

Ho provato a inviarmi una email con all'interno il link:

http://www.dbltest.com/

ed è passata senza alcun score URIBL_*...

--
Microsoft is to Software as McDonalds is to Cuisine.

[writethem]

>
> Ho provato a inviarmi una email con all'interno il link:
>
> http://www.dbltest.com/
>
> ed è passata senza alcun score URIBL_*...
>

una domanda: il mailserver come risolve le query dns? passando da un
server dns di un provider o direttamente?

dig che dice facendo la query di test?

[Marco Gaiarin]

Mandi! writethem
In chel di` si favelave...

> una domanda: il mailserver come risolve le query dns? passando da un
> server dns di un provider o direttamente?

Provider. Anzi, providers (ho due linee da provider diversi in load
balancing.

> dig che dice facendo la query di test?

Sembra funzionare:

gaio@armitage:~$ dig +noall +comments +answ a dbltest.com.dbl.spamhaus.org.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8119
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 20, ADDITIONAL: 0

;; ANSWER SECTION:
dbltest.com.dbl.spamhaus.org. 60 IN A 127.0.1.2

--
Io chiedo quando sara` che l'uomo potra` imparare
a vivere senza ammazzare e il vento si posera` (F. Guccini)

[Marco Gaiarin]

Mandi! Skull

In chel di` si favelave...

> E' chiamato "deep header parsing", per la cronaca.

Grazie.

> Ha alcuni caveat, perchè non tutte le dnsbl sono adatte a questo genere
> di utilizzo.

Immagino. Giusto per la tua esperienza, ti sei fatto una idea di score che
possono essere applicati qui in italia con efficacia?

--
If SMB was an animal it would go wolf and most people would have shot it
or put it down humanely. (Rod Boyce)

[Marco Gaiarin]

Mandi! writethem
In chel di` si favelave...

>> Quindi in teoria dovrebbe/potrebbe alzare lo score di spamness di un
>> messaggio transitato per smtp leciti ma proveniente d uno non lecito.
> postfix fa un reject o un accept, non interviene sullo score

Mi sono espresso da cani. Volevo dire che postfix (diciamo il MTA, io uso
exim ;) usa le RBL ma contro l'IP chiamante, non va a fare una verifica
degli hop (Received).
Quindi l'uso delle RBL da parte dell'MTA e da parte di SA è ''diverso'', ed
è sensato che lo facciano tutti e due...

>> #skip_rbl_checks 1
> perchè?
> leggo:
> skip_rbl_checks ( 0 | 1 ) (default: 0)
> Turning on the skip_rbl_checks setting will disable the DNSEval plugin,
> which implements Real-time Block List (or: Blackhole List) (RBL) lookups.

C'è il commento, e il default è '0'. ;-)
[si, sono contorto, potevo evitare di pastare la riga, scusa... ;)]

>> e non ho uno solo score che contenga una URIBL_* ...
> che query hai messo? non vorrei tu abbia copiato dal mio messaggio
> precedente. come giustamente diceva skull, l'espressione [2-6] non viene
> letta da spamassassin, vanno fatte righe separate 127.0.1.102, 103, 104 etc.

Uso sa-update, e ho verificato che negli update le query sono corrette.

--
Le vie del Signore sono infinite.
E' la segnaletica che lascia a desiderare...

[Skull]

On 01/02/15 18:26, Marco Gaiarin wrote:

>> Ha alcuni caveat, perchè non tutte le dnsbl sono adatte a questo genere
>> di utilizzo.
>
> Immagino. Giusto per la tua esperienza, ti sei fatto una idea di score che
> possono essere applicati qui in italia con efficacia?

Non saprei rispondere in maniera semplice, perchè da tempo non uso XBL
in quanto tale, in quel ruolo, ma una lista specificamente composta dai
soli IP ospitanti bot noti per abusare SMTP-AUTH...

Ma, come detto, se dovessi farlo oggi (come lo feci in passato), non lo
farei "a tappeto", ma solo in corrispondenza di altri indicatori che
facciano pensare ad un utilizzo abusivo dell'account.
E temo che canali pubblici quale questo siano inadatti a dare dettaglio
di cosa e come...

[Marco Gaiarin]

Mandi! Skull
In chel di` si favelave...

> Ma, come detto, se dovessi farlo oggi (come lo feci in passato), non lo
> farei "a tappeto", ma solo in corrispondenza di altri indicatori che
> facciano pensare ad un utilizzo abusivo dell'account.
> E temo che canali pubblici quale questo siano inadatti a dare dettaglio
> di cosa e come...

Capisco. ;-)

--
Voi avevate voci potenti, lingue allenate a battere il tamburo
voi avevate voci potenti, adatte per il vaffanculo (F. De Andre`)