You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Cedric Knight <ce...@gn.apc.org> on 2010/12/13 14:47:14 UTC

Two newish RBLs; NXDOMAIN question

There seem to be an abundance of DNSBLs out there nowadays.  Here are
my observations on two, and an implementation question.  The Good, the
Bad and the Ugly:

GBUdb.com's truncated list (http://www.gbudb.com/truncate/) went public
in May and seems to work very well, catching a lot of things missed by
other RBLs, with <1% false positives.  YMMV.  It's related to Message
Sniffer, a commercial anti-spam package, and is fully automated (no user
submissions).  I'd hazard that a starting score of 2.0 might be appropriate.

header RCVD_IN_GBUDB_TRUNC      eval:check_rbl('trunc-firsttrusted',
'truncate.gbudb.net.')
describe RCVD_IN_GBUDB_TRUNC    Connecting IP in truncate.gbudb.net.
score RCVD_IN_GBUDB_TRUNC       1.5
tflags RCVD_IN_GBUDB_TRUNC      net

I've also had good experiences with bl.mailspike.net and the dynamic and
noptr lists on spamrats (all.spamrats.com 127.0.0.3[67]).  WPBL seems to
be less useful than two years ago, with too many FPs.

QUORUM.TO is a recent project of Julian Haight, creator of SpamAssassin.
Some data is commercial, but there's also a public list, described at
http://www.quorum.to/publicbl.html.  I'm disappointed by my tests so
far, showing its "base rule" as very fuzzy in distinguishing between ham
and spam.  In addition, quorum.to doesn't follow RFC 5782 convention,
for example in its negative response to 2.0.0.127.list.quorum.to.  In
fact, I was most hopeful of using it as a cleanlist of hosts that had
deliberately validated themselves, as it gives a positive response
(127.0.0.0) for IPv4 addresses it has no data for.  I've been trying it
out with the following rules, but I wouldn't suggest anyone else does at
the moment:

header __RCVD_IN_QUORUM         eval:check_rbl('quorum-firsttrusted',
'list.quorum.to.')
describe __RCVD_IN_QUORUM       Connecting IP in list.quorum.to.
tflags __RCVD_IN_QUORUM         net

header RCVD_IN_QUORUM_BLOCK
eval:check_rbl_sub('quorum-firsttrusted', '^127\.0\.0\.2$')
describe RCVD_IN_QUORUM_BLOCK   Connecting IP failed quorum.to tests
score RCVD_IN_QUORUM_BLOCK      0.1
tflags RCVD_IN_QUORUM_BLOCK     net

header RCVD_IN_QUORUM_REJECT
eval:check_rbl_sub('quorum-firsttrusted', '^127\.0\.0\.[45]$')
describe RCVD_IN_QUORUM_REJECT  quorum.to has been asked to dirtylist
connecting IP
score RCVD_IN_QUORUM_REJECT     0.01
tflags RCVD_IN_QUORUM_REJECT    net

meta RCVD_IN_QUORUM_GOOD        (! __RCVD_IN_QUORUM)
describe RCVD_IN_QUORUM_GOOD    Connecting IP not listed on quorum.to
(or servfail)
score RCVD_IN_QUORUM_GOOD       -0.1
tflags RCVD_IN_QUORUM_GOOD      net

As you can see, the only way to turn use it as a list of clean IPs is to
negate any response.  My problem, rather theoretical, is that as well as
catching an NXDOMAIN response, the cleanlisting (RCVD_IN_QUORUM_GOOD)
will trigger on bad configuration (SERVFAIL) or network problems, and it
appears SA's Dns module treats all those conditions the same.
Intuitively, I'd like to be able to do something like (invalid code
follows):

  header RCVD_IN_QUORUM_GOOD2
eval:check_rbl_sub('quorum-firsttrusted', 'NXDOMAIN')

or maybe

  header RCVD_IN_QUORUM_GOOD2
eval:check_rbl_sub('quorum-firsttrusted', '^$')

Does anyone else think work on providing such a facility for negative
cleanlists might be worthwhile?

CK

Re: Two newish RBLs; NXDOMAIN question

Posted by Cedric Knight <ce...@gn.apc.org>.
On 13/12/10 15:44, RW wrote:
> On Mon, 13 Dec 2010 13:47:14 +0000
> Cedric Knight <ce...@gn.apc.org> wrote:
...
>> header RCVD_IN_GBUDB_TRUNC      eval:check_rbl('trunc-firsttrusted',
>> 'truncate.gbudb.net.')
>
> That should be "-lastexternal"  -  assuming that the list contains
> a lot of dynamic addresses.

And assuming that you've populated trusted_networks with the SMTP
servers for ISPs/freemailers that don't put any authentication
information in the header.  I haven't, personally.

The list doesn't contain a lot of dynamic addresses in the sense of
RCVD_IN_SORBS_DUL, but I'm not sure it excludes them the way
deep-parsing lists are supposed to.

> Blacklists run on either the last external address or run deep,
> whitelists run on first-trusted.

I guess this one could run deep, and will try that for a period.

This is a confusing issue. The way I think of it goes roughly as follows:

* I prefer not to do unnecessary DNS lookups, ideally at most one per
message (per RBL).

* If I know another party's server forwards a domain it MXes to me, but
is also a MSA (SMTP server) for users, then I don't want to put it in
internal_networks, to prevent possible DUL FPs from the SMTP users.

* So, assuming my spam-checking is better than on that server, I put it
in trusted_networks.  Now -firsttrusted rules will catch spam sent to
the MX, but will not hit the other server's users, unless they are on a
dynamic IP address that has unfortunately recently been used by spammers
and there is no SA-recognised authentication such as ESMTPA (a risk I
can take).  This is a conservative approach to trusted_networks.  (And a
bit lazy, perhaps: I do have a list of mx-like servers that have sent
ham, but I don't want to keep updating it.)

* If I put all major ISPs and freemailers into firsttrusted, and some of
them do have authentication that is recognised by SpamAssassin (such as
Yahoo), then the RBL won't catch exploited servers or botnets or gangs
in West Africa who have freemail accounts or are on the ISP's network;
in fact ALL_TRUSTED might hit (btw I shortcircuit if so, to stop
CPU-intensive rules running).

* With this approach, -lastexternal still catches botnet spam coming
from dynamic and dsl IP addresses direct to my MXs (and any MXs I list
that are not also MSAs), by using the dial-up RBLs like SORBS_DUL.  For
a more general RBL (ie just including addresses known to send spam, not
based on whether they are dynamic), -firsttrusted hits botnet spam
sources, but also stuff from a compromised server.

* Suppose I do add Hotmail: "trusted_networks 65.52.0.0/14".  Hotmail's
auth mechanism is not recognised by SA (unlike Yahoo's).  Now if I set
an RBL to run -lastexternal, it will check whether Hotmail is in the RBL
(or maybe shouldn't check at all since it's trusted).  That Hotmail
server may send a mixture of ham and spam, and I don't expect it to be
listed as a spam source.  If I have the list (which is mostly of
addresses that are known spam sources, not just dynamic or IPs or ones
which are known not to run mailservers) set to -firsttrusted, it stands
a fair chance of discriminating between spammy and non-spammy Hotmail users.

* DNSWLs stay on -firsttrusted too.

I know this goes against received wisdom, but empirically it seems to
work well for me.

CK

Re: Two newish RBLs; NXDOMAIN question

Posted by RW <rw...@googlemail.com>.
On Mon, 13 Dec 2010 13:47:14 +0000
Cedric Knight <ce...@gn.apc.org> wrote:

> GBUdb.com's truncated list (http://www.gbudb.com/truncate/) went
> public in May and seems to work very well, catching a lot of things
> missed by other RBLs, with <1% false positives.  YMMV.  It's related
> to Message Sniffer, a commercial anti-spam package, and is fully
> automated (no user submissions).  I'd hazard that a starting score of
> 2.0 might be appropriate.
> 
> header RCVD_IN_GBUDB_TRUNC      eval:check_rbl('trunc-firsttrusted',
> 'truncate.gbudb.net.')

That should be "-lastexternal"  -  assuming that the list contains
a lot of dynamic addresses. 

Blacklists run on either the last external address or run deep,
whitelists run on first-trusted.

Re: Two newish RBLs; NXDOMAIN question

Posted by Michael Scheidell <mi...@secnap.com>.
On 12/13/10 10:54 AM, Cedric Knight wrote:
> On 13/12/10 15:06, Karsten Bräckelmann wrote:
>>> [...] is a recent project of Julian Haight, creator of Spam
>> Cop. SpamCop.
>>
>>> Assassin.
> Oh no, did I type that?  Dratted absent-minded fingers.
>
and,similar to spamcop, (which was sold to ironport, then cisco), it 
will blacklist aol and yahoo addresses on occasion.  so, DON'T use it in 
prequeue.


> Apologies.
>
> C


-- 
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
ISN: 1259*1300
 >*| *SECNAP Network Security Corporation

    * Certified SNORT Integrator
    * 2008-9 Hot Company Award Winner, World Executive Alliance
    * Five-Star Partner Program 2009, VARBusiness
    * Best in Email Security,2010: Network Products Guide
    * King of Spam Filters, SC Magazine 2008

______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________  

Re: Two newish RBLs; NXDOMAIN question

Posted by Cedric Knight <ce...@gn.apc.org>.
On 13/12/10 15:06, Karsten Bräckelmann wrote:
>> [...] is a recent project of Julian Haight, creator of Spam
> 
> Cop. SpamCop.
> 
>> Assassin.

Oh no, did I type that?  Dratted absent-minded fingers.

Apologies.

C

Re: Two newish RBLs; NXDOMAIN question

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
> [...] is a recent project of Julian Haight, creator of Spam

Cop. SpamCop.

> Assassin.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: Two newish RBLs; NXDOMAIN question

Posted by Benny Pedersen <me...@junc.org>.
On tir 14 dec 2010 18:55:12 CET, Oguz Yilmaz wrote

> Thanks, a basic tcpdump revealed the method of query and response.

i like comal more then basic, but glad to be of help

-- 
xpoint http://www.unicom.com/pw/reply-to-harmful.html



Re: Two newish RBLs; NXDOMAIN question

Posted by Oguz Yilmaz <og...@gmail.com>.
Thanks, a basic tcpdump revealed the method of query and response.

--
Oguz YILMAZ



On Tue, Dec 14, 2010 at 6:47 PM, Benny Pedersen <me...@junc.org> wrote:
> On tir 14 dec 2010 07:50:17 CET, Oguz Yilmaz wrote
>>>
>>> and you can't resolve zen.spamhaus.org, either.  :)
>>
>> Does it mean they are closed?
>
> rndc querylog
> spamassassin -t spammsg
> rndc querylog
>
> see log
>
> above works when running bin9
>
> --
> xpoint http://www.unicom.com/pw/reply-to-harmful.html
>
>

Re: Two newish RBLs; NXDOMAIN question

Posted by Benny Pedersen <me...@junc.org>.
On tir 14 dec 2010 07:50:17 CET, Oguz Yilmaz wrote
>> and you can't resolve zen.spamhaus.org, either.  :)
> Does it mean they are closed?

rndc querylog
spamassassin -t spammsg
rndc querylog

see log

above works when running bin9

-- 
xpoint http://www.unicom.com/pw/reply-to-harmful.html


Re: Two newish RBLs; NXDOMAIN question

Posted by RW <rw...@googlemail.com>.
On Tue, 14 Dec 2010 08:50:17 +0200
Oguz Yilmaz <og...@gmail.com> wrote:

> On Mon, Dec 13, 2010 at 7:21 PM, Len Conrad <LC...@go2france.com>
> wrote:
> >
> >>Are you sure? At the moment I can not resolv the name
> >>truncate.gbudb.net.
> >
> > that's correct, and OK.
> >
> > and you can't resolve zen.spamhaus.org, either.  :)
> 
> Does it mean they are closed?

It means that there is no reason for either to have an A-record.

Re: Two newish RBLs; NXDOMAIN question

Posted by Oguz Yilmaz <og...@gmail.com>.
On Mon, Dec 13, 2010 at 7:21 PM, Len Conrad <LC...@go2france.com> wrote:
>
>>Are you sure? At the moment I can not resolv the name truncate.gbudb.net.
>
> that's correct, and OK.
>
> and you can't resolve zen.spamhaus.org, either.  :)

Does it mean they are closed?

>
> truncate is a good RBL, in my experience of a couple months.  Its picks up some bad stuff that gets past b.barracuda and zen.
>
>
>
> Len
>
>
>
>
>
>
>>--
>>Oguz YILMAZ
>>
>>
>>
>>On Mon, Dec 13, 2010 at 6:22 PM, Marc Perkel
>><su...@junkemailfilter.com> wrote:
>>>
>>>
>>> On 12/13/2010 5:47 AM, Cedric Knight wrote:
>>>>
>>>> GBUdb.com's truncated list (http://www.gbudb.com/truncate/) went public
>>>> in May and seems to work very well, catching a lot of things missed by
>>>> other RBLs, with<1% false positives.  YMMV.  It's related to Message
>>>> Sniffer, a commercial anti-spam package, and is fully automated (no user
>>>> submissions).  I'd hazard that a starting score of 2.0 might be
>>>> appropriate.
>>>
>>> Very good. I just set it up and it seems to be doing well for me so far.
>>> Thanks for the tip.
>>>
>>> --
>>> Marc Perkel - Sales/Support
>>> support@junkemailfilter.com
>>> http://www.junkemailfilter.com
>>> Junk Email Filter dot com
>>> 415-992-3400
>>>
>>>
>
>
>
>

Re: Two newish RBLs; NXDOMAIN question

Posted by Len Conrad <LC...@Go2France.com>.
>Are you sure? At the moment I can not resolv the name truncate.gbudb.net.

that's correct, and OK.  

and you can't resolve zen.spamhaus.org, either.  :)

truncate is a good RBL, in my experience of a couple months.  Its picks up some bad stuff that gets past b.barracuda and zen. 



Len






>--
>Oguz YILMAZ
>
>
>
>On Mon, Dec 13, 2010 at 6:22 PM, Marc Perkel
><su...@junkemailfilter.com> wrote:
>>
>>
>> On 12/13/2010 5:47 AM, Cedric Knight wrote:
>>>
>>> GBUdb.com's truncated list (http://www.gbudb.com/truncate/) went public
>>> in May and seems to work very well, catching a lot of things missed by
>>> other RBLs, with<1% false positives.  YMMV.  It's related to Message
>>> Sniffer, a commercial anti-spam package, and is fully automated (no user
>>> submissions).  I'd hazard that a starting score of 2.0 might be
>>> appropriate.
>>
>> Very good. I just set it up and it seems to be doing well for me so far.
>> Thanks for the tip.
>>
>> --
>> Marc Perkel - Sales/Support
>> support@junkemailfilter.com
>> http://www.junkemailfilter.com
>> Junk Email Filter dot com
>> 415-992-3400
>>
>>




Re: Two newish RBLs; NXDOMAIN question

Posted by Oguz Yilmaz <og...@gmail.com>.
Are you sure? At the moment I can not resolv the name truncate.gbudb.net.


--
Oguz YILMAZ



On Mon, Dec 13, 2010 at 6:22 PM, Marc Perkel
<su...@junkemailfilter.com> wrote:
>
>
> On 12/13/2010 5:47 AM, Cedric Knight wrote:
>>
>> GBUdb.com's truncated list (http://www.gbudb.com/truncate/) went public
>> in May and seems to work very well, catching a lot of things missed by
>> other RBLs, with<1% false positives.  YMMV.  It's related to Message
>> Sniffer, a commercial anti-spam package, and is fully automated (no user
>> submissions).  I'd hazard that a starting score of 2.0 might be
>> appropriate.
>
> Very good. I just set it up and it seems to be doing well for me so far.
> Thanks for the tip.
>
> --
> Marc Perkel - Sales/Support
> support@junkemailfilter.com
> http://www.junkemailfilter.com
> Junk Email Filter dot com
> 415-992-3400
>
>

Re: Two newish RBLs; NXDOMAIN question

Posted by Marc Perkel <su...@junkemailfilter.com>.

On 12/13/2010 5:47 AM, Cedric Knight wrote:
> GBUdb.com's truncated list (http://www.gbudb.com/truncate/) went public
> in May and seems to work very well, catching a lot of things missed by
> other RBLs, with<1% false positives.  YMMV.  It's related to Message
> Sniffer, a commercial anti-spam package, and is fully automated (no user
> submissions).  I'd hazard that a starting score of 2.0 might be appropriate.

Very good. I just set it up and it seems to be doing well for me so far. 
Thanks for the tip.

-- 
Marc Perkel - Sales/Support
support@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400