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:[EMAIL PROTECTED]
Sent: Tuesday, February 08, 2005 6:37 PM
To: [EMAIL PROTECTED]; 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...
