Spamhaus sta per rilasciare una nuova DNSBL.
Questa volta l’attenzione si rivolge non più al listing di IP (come nel caso di SBL, XBL e PBL), ma al listing di domini, indirizzandosi ad una tipologia di utilizzo sovrapponibile alle oramai consolidate SURBL e URIBL. In altre parole, è pensata per il lookup dei domini linkati nelle email.
DBL verrà rilasciata ufficialmente il 1° marzo; poichè le specifiche di implementazione richiedono alcune variazioni al codice di lookup di SpamAssassin, gli utenti di quest’ultimo sono invitati ad attendere l’uscita delle release 3.3.1 di tale framework di filtraggio, che dovrebbe avvenire all’incirca negli stessi giorni e includere già il supporto a DBL.
In virtù della “amicizia” con Spamhaus , in realtà, nel momento in cui scrivo DBL sta già venendo utilizzata in produzione dai nostri sistemi da alcune settimane, ed è stata usata in testing (ovvero limitandoci a monitorarne il comportamento senza usarla in blocco) per alcuni mesi prima di ciò, utilizzandola in modo assolutamente analogo a SURBL per tramite di milter-link.
I risultati sono pregevoli, se si considera la policy “Zero False Positive” che DBL si prefigge (finora confermata a pieno titolo dai dati), anche se in termini di hits al momento SURBL le è superiore (dalle mie rilevazioni, tutt’altro che scientifiche, al momento) di un fattore compreso tra 3X e 5X.
Skull's blog 
[…] l’occasione, voglio precisare una osservazione riguardo a quanto affermavo pochi giorni fa sull’uso di DBL con software (quale milter-link) non predisposto per le query […]
Da altre statistiche che vedo DBL sembra essere simile a SURBL in termini di hits, anzi un pochino piu’ alto. Vedi ad esempio:
http://www.intra2net.com/en/support/antispam/index.php
(ma altre locazioni riportano risultati simili).
Quindi il fattore tra 3X e 5X cha dai mi perplime.
Probabile sia un effetto della vista assolutamente locale alla base delle rilevazioni succitate, e del fatto che la mia statistica è assolutamente spannometrica…
Se osservo il numero di reject causati da multi.surbl.org negli ultimi giorni vedo questo:
20100308: 1097
20100309: 821
20100310: 908
20100311: 1523
20100312: 1014
20100313: 898
20100314: 820
20100315: 862
Per DBL:
20100308: 519
20100309: 423
20100310: 571
20100311: 793
20100312: 259
20100313: 196
20100314: 256
20100315: 541
Le query che causano i reject avvengono in parallelo e vale la prima hit positiva ricevuta, quindi non c’è un effetto di mascheramento dovuto all’ordinamento del ruleset (che vede peraltro DBL per prima).
Inoltre, entrambe le liste sono interrogate sullo stesso pool di istanze locali di RBLDNSD, quindi hanno la stessa latenza intrinseca…
Entrambi i dati sopra riportati si riferiscono all’utilizzo solamente come BL di URI, per coerenza di utilizzo.
Quindi DBL è penalizzata dal fatto che in quella statistica non risultano a suo favore i blocchi applicati usandola sui dati di envelope (HELO, rDNS, sender), che indubbiamente son bei numeri:
20100308: 368
20100309: 499
20100310: 742
20100311: 1423
20100312: 649
20100313: 446
20100314: 318
20100315: 652
Però:
– questi numeri vanno a loro volta a discapito di SBL, in massima parte (credo, ma tu avrai più dettaglio di me al riguardo…)
– non sono confrontabili con SURBL, che non prevede questo utilizzo
– mi aspetto che in larga parte ripuliscano il flusso da snowshoe ma abbiano ben scarso effetto su botnet spam, che è dove si fanno i grossi numeri con l’approccio URI-based
Ribadisco che comunque sono numeri che saltano fuori dalla nostra realtà di produzione, quindi pesantemente viziati da una struttura di filtraggio che non è pensata per ricavare quei numeri in modo asettico e neutrale…
Chi porti la sessione fino ad end-of-DATA anche quando filtrabile in envelope vedrà certamente numeri completamente diversi.