You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Shane Metler <me...@homes.com> on 2005/02/08 20:56:34 UTC

custom URIDNSBL rules

Hi SA Users,
 
I have a question for anyone who may have added their own custom
URIDNSBL lookups.
 
I have set up RBLDNSD (successfully as far as I can see) to support both
IPs and URIs.
 
A command line DNS call returns the expected results, but SA 3.0.0 and
URIDNSBL do not 'see' that the queried URI A record is being returned
from my local RBLDNSD zone. Is there anything that I am missing that
would help SA and URIDNSBL to pick up on the fact that my local RBLDNSD
zone has that URI listed?
 
I've added the custom rule to run a URIDNSBL check on my local RBLDNSD
server:
 
# custom URIBL
urirhssub     URIBL_HOMES    auth2.homes.com.    A    2
header        URIBL_HOMES    eval:check_uridnsbl('URIBL_HOMES')
describe      URIBL_HOMES    Contains an URL in the Homes.com URI
blocklist
tflags          URIBL_HOMES    net
score          URIBL_HOMES    1    1    1    1
 
I can see that SA is calling my local RBLDNSD server at auth2.homes.com"
from SA's DEBUG output:
 
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x898ffe4)
implements 'check_tick'
debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up
(auth2.homes.com.:broadcastemail.us)"
debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_AB_SURBL):
127.0.0.102
debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_SC_SURBL):
127.0.0.102
debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_WS_SURBL):
127.0.0.102
debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up
(multi.surbl.org.:broadcastemail.us)
debug: URIDNSBL: queries completed: 3 started: 2
debug: URIDNSBL: queries active:  at Tue Feb  8 14:49:15 2005

 
 
I have the URI "broadcastemail.us" entered into the RBLDNSD zone. On the
command line, the command: " dig @auth2.homes.com
broadcastemail.us.auth2.homes.com A ", returns the expected A record:

; <<>> DiG 9.2.1 <<>> @auth2.homes.com broadcastemail.us.auth2.homes.com
A
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13923
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
;; QUESTION SECTION:
;broadcastemail.us.auth2.homes.com. IN  A
 
;; ANSWER SECTION:
broadcastemail.us.auth2.homes.com. 2100 IN A    127.0.0.2
 
;; Query time: 0 msec
;; SERVER: 199.44.153.104#53(auth2.homes.com)
;; WHEN: Tue Feb  8 14:44:43 2005
;; MSG SIZE  rcvd: 67



Thanks in advance,
Shane Metler


Re: custom URIDNSBL rules

Posted by Jeff Chan <je...@surbl.org>.
On Tuesday, February 8, 2005, 3:37:05 PM, Matt Kettler wrote:
> At 02:56 PM 2/8/2005, Shane Metler wrote:
>>debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x898ffe4) 
>>implements 'check_tick'
>>debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up 
>>(auth2.homes.com.:broadcastemail.us)"
>>debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_AB_SURBL): 
>>127.0.0.102
>>debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_SC_SURBL): 
>>127.0.0.102
>>debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_WS_SURBL): 
>>127.0.0.102
>>debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up 
>>(multi.surbl.org.:broadcastemail.us)
>>debug: URIDNSBL: queries completed: 3 started: 2
>>debug: URIDNSBL: queries active:  at Tue Feb  8 14:49:15 2005
>>
>>
>>I have the URI "broadcastemail.us" entered into the RBLDNSD zone. On the 
>>command line, the command: " dig @auth2.homes.com 
>>broadcastemail.us.auth2.homes.com A ", returns the expected A record:

> What happens if you try that dig statement WITHOUT the @auth2.homes.com to 
> force the query to a particular name server?

> i.e.:

>          dig broadcastemail.us.auth2.homes.com

> Remember, SA is just going to do a general resolve. It's not going to force 
> the queried name server to be auth2.homes.com. It's just going to query 
> that domain using your normal resolv.conf servers...

Exactly.  The problem is that "dig @auth2.homes.com" forces the
queries to go to a specific server, presumably the name of your
rbldnsd server.  SA is going to use whatever resolver the system
it's on is configured to use.

What you should do is set up forwarding for the "auth2.homes.com"
custom zone (and any other rbldnsd zones locally served) from your
BIND server to your rbldnsd server.  See for examples:

  http://njabl.org/rsync.html
  http://www.surbl.org/rbldnsd-howto.html
  http://www.surbl.org/rbldnsd-bind-freebsd.html

Jeff C.
-- 
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/


RE: custom URIDNSBL rules

Posted by me...@homes.com.
Thanks Matt, Jeff, and Paul for your input and suggestions.

DNS is set up correctly (not RBLDNSD, but our normal DNS setup is pointing
to auth2.homes.com), so "dig broadcastemail.us.auth2.homes.com" returns the
correct reply.

I added some more debug code to URIDNSBL.pm and could see that the URIDNSBL
A record request was getting back auth2.homes.com's assigned IP and not the
expected 127.0.0.2. This is why SA was not showing the URI lookup was
successful. 

After looking a little more, I saw that URIDNSBL was getting
auth2.homes.com's assigned IP for *every* request, not just for the URI's
that were indexed in RBLDNSD's zone files ... ?

I did figure out a quick fix, and that was to place the string "127.0.0.2"
in RBLDNSD's TXT record reply (it was already assigned as the A record
reply), then I changed the URIDNSBL rule to check TXT records instead of A
records ... all of a sudden URIDNSBL was seeing the correct TXT reply, and
the sub query was matching the 127.0.0.2 for successful lookups.

# custom URIBL
urirhssub     URIBL_HOMES    auth2.homes.com.    TXT    127.0.0.2
header        URIBL_HOMES    eval:check_uridnsbl('URIBL_HOMES')
describe      URIBL_HOMES    Contains an URL in the Homes.com URI blocklist
tflags        URIBL_HOMES    net
score         URIBL_HOMES    1    1    1    1


# RBLDNSD data file
:127.0.0.2: 127.0.0.2 - $ is a banned URI
broadcastemail.us
broadcastemail.com
broadcastemail.net


I still can't figure out why URIDNSBL receives the correct TXT record, but
does not receive 127.0.0.2 for A record lookups.

I imagine I don't need to be running the URIDNSBL 'sub' query test, but
after my custom URIDNSBL rule was being triggered for *every* A record
lookup, I'd like to keep this 'sub' query as added insurance that the
URIDNSBL code is matching only URIs indexed in RBLDNSD's zones.

Thanks again for your help and insight!!
Shane Metler





-----Original Message-----
From: Matt Kettler [mailto:mkettler@evi-inc.com] 
Sent: Tuesday, February 08, 2005 6:37 PM
To: metlers@homes.com; users@spamassassin.apache.org
Subject: Re: custom URIDNSBL rules

At 02:56 PM 2/8/2005, Shane Metler wrote:
>debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x898ffe4) 
>implements 'check_tick'
>debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up 
>(auth2.homes.com.:broadcastemail.us)"
>debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_AB_SURBL): 
>127.0.0.102
>debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_SC_SURBL): 
>127.0.0.102
>debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_WS_SURBL): 
>127.0.0.102
>debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up 
>(multi.surbl.org.:broadcastemail.us)
>debug: URIDNSBL: queries completed: 3 started: 2
>debug: URIDNSBL: queries active:  at Tue Feb  8 14:49:15 2005
>
>
>I have the URI "broadcastemail.us" entered into the RBLDNSD zone. On the 
>command line, the command: " dig @auth2.homes.com 
>broadcastemail.us.auth2.homes.com A ", returns the expected A record:

What happens if you try that dig statement WITHOUT the @auth2.homes.com to 
force the query to a particular name server?

i.e.:

         dig broadcastemail.us.auth2.homes.com

Remember, SA is just going to do a general resolve. It's not going to force 
the queried name server to be auth2.homes.com. It's just going to query 
that domain using your normal resolv.conf servers...




Re: custom URIDNSBL rules

Posted by Matt Kettler <mk...@evi-inc.com>.
At 02:56 PM 2/8/2005, Shane Metler wrote:
>debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x898ffe4) 
>implements 'check_tick'
>debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up 
>(auth2.homes.com.:broadcastemail.us)"
>debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_AB_SURBL): 
>127.0.0.102
>debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_SC_SURBL): 
>127.0.0.102
>debug: URIDNSBL: domain "broadcastemail.us" listed (URIBL_WS_SURBL): 
>127.0.0.102
>debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up 
>(multi.surbl.org.:broadcastemail.us)
>debug: URIDNSBL: queries completed: 3 started: 2
>debug: URIDNSBL: queries active:  at Tue Feb  8 14:49:15 2005
>
>
>I have the URI "broadcastemail.us" entered into the RBLDNSD zone. On the 
>command line, the command: " dig @auth2.homes.com 
>broadcastemail.us.auth2.homes.com A ", returns the expected A record:

What happens if you try that dig statement WITHOUT the @auth2.homes.com to 
force the query to a particular name server?

i.e.:

         dig broadcastemail.us.auth2.homes.com

Remember, SA is just going to do a general resolve. It's not going to force 
the queried name server to be auth2.homes.com. It's just going to query 
that domain using your normal resolv.conf servers...