You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Matthew Romanek <sh...@gmail.com> on 2004/12/06 17:27:58 UTC
Further URIDNSBL problems..
Okay, after my last post, I had the amazingly bright idea to feed
spamd some mail in debug mode. It showed pretty clearly that all the
DNS lookups were timing out at 15 seconds. I increased the timeout to
30, and now things are resolving at 17 seconds. Duh.
However, I'm still not seeing anything getting marked, including
SURBL's test URI. An excerpt, for your perusal:
$ spamassassin -D < test-email 2>&1 | less
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x9667b44)
implements 'parsed_metadata'
debug: uri found: http://www.surbl-org-permanent-test-point.com/
debug: URIDNSBL: domains to query: surbl-org-permanent-test-point.com
debug: is Net::DNS::Resolver available? yes
debug: Net::DNS version: 0.48
...
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x9667b44)
implements 'check_tick'
debug: URIDNSBL: query for surbl-org-permanent-test-point.com took 221
seconds to look up
(multi.surbl.org.:surbl-org-permanent-test-point.com)
debug: URIDNSBL: queries completed: 2 started: 0
debug: URIDNSBL: queries active: at Mon Dec 6 08:11:22 2004
...
debug: RBL: success for 11 of 11 queries
...
debug: tests=AWL,BAYES_00,NO_DNS_FOR_FROM,RCVD_BY_IP
debug: subtests=__CT,__CTE,__CT_TEXT_PLAIN,__HAS_MSGID,__HAS_SUBJECT,__MIME_VERSION,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__MSGID_RANDY,__SANE_MSGID
Looking at other emails, and spamd's debug output, I see a lot of
domain queries being run, and succeeding now, but in the last 50
spams, not one has hit on any DNSBL or URIBL. Of course, that's
technically possible, but that's why I tried the test URI.
Does anyone have any idea as to what I can look into next? Or some
other way to test it, perhaps?
The RBLs worked fine on 2.6, but haven't been working since going to 3.0.1.
Thanks!
--
Matthew 'Shandower' Romanek
IDS Analyst
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Matthew Romanek <sh...@gmail.com>.
> Note that only 18 of the tests failed. P_1, 3, 4, 5 and 6 seemed to work?
Scratch that last comment. They very clearly aren't working, just from
that snippit. That's me getting desperate-yet-hopeful. :)
--
Matthew 'Shandower' Romanek
IDS Analyst
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Matt Kettler <mk...@evi-inc.com>.
At 11:22 AM 12/8/2004, Matthew Romanek wrote:
>FYI (and for future list-searchers), the problem with URIDNSBL
>appearing to work but not actually scoring was because the host's
>resolv.conf included 127.0.0.1, which apparently something doesn't
>like.
Really? I do this all the time.. However, you better make sure that the
machine is running a working DNS server when you do this. If it's not, then
putting 127.0.0.1 in resolv.conf WILL break SA.
Unlike a lot of other apps, SA's methods of calling DNS don't seem to
always query all the DNS servers listed in resolv.conf, so make sure the
first one is a valid entry.
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by mouss <us...@free.fr>.
Jeff Chan wrote:
>
> Thanks for the feedback Matthew. Mouss would you care to report
> the bug to Fedora, if you haven't already? (It sounds like it
> was somewhat known already?)
I don't know much about it except, that the "old" bind docs say so.
See section 6.2 of the "BOG"
(http://www.ccs.neu.edu/groups/systems/proj/DNS/bog.html for instance).
<excerpt BOG-sect-6.2>
Note that if you wish to list the local host in your resolver
configuration file, you should probably use its primary Internet address
rather than a localhost alias such as 127.0.0.1 or 0.0.0.0. This is due
to a bug in the handling of connected SOCK_DGRAM sockets in some
versions of the BSD networking code. If you must use an address-alias,
you should prefer 0.0.0.0 (or simply ``0'') over 127.0.0.1, though be
warned that depending on the vintage of your BSD-derived networking
code, both of them are capable of failing in their own ways.
</excerpt>
(Of course, "BSD" doesn't mean just the open-src *bsd here, as it
applies to all OSes that used the BSD sockets code, and this includes a
lot of systems)
regards,
mouss
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Kelson <ke...@speed.net>.
Jeff Chan wrote:
>>>Matthew
>>>Was the OS Fedora Core 1 for this bug?
>>>
>>>Mouss,
>>>If there's a bug would you please submit it to them?
FYI, Fedora Core 1 has already been EOL'ed. They're currently providing
fixes for FC2 and FC3, and FC2 will be dropped when the first FC4 beta
is released. Unless the bug is still in FC2 or FC3, the place to send
the bug report would be the Fedora Legacy project, which is currently
handling fixes for Red Hat 7.3 and 9, and Fedora Core 1. (Fedora Legacy
is focused mainly on security fixes, though.)
http://www.fedoralegacy.org/
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Jeff Chan <je...@surbl.org>.
On Tuesday, February 8, 2005, 10:27:21 PM, Matthew Romanek wrote:
> On Tue, 8 Feb 2005 17:34:44 -0800, Jeff Chan <je...@surbl.org> wrote:
>> On Tuesday, February 8, 2005, 4:52:53 PM, mouss mouss wrote:
>> > Jeff Chan wrote:
>> >> On Wednesday, December 8, 2004, 8:22:24 AM, Matthew Romanek wrote:
>> >>
>> >>>FYI (and for future list-searchers), the problem with URIDNSBL
>> >>>appearing to work but not actually scoring was because the host's
>> >>>resolv.conf included 127.0.0.1, which apparently something doesn't
>> >>>like.
>>
>> > use 0.0.0.0 instead of 127.0.0.1, or better, an IP of one of the
>> > physical interfaces. there seems to be a bug with sock_dgram code.
>>
>> Matthew
>> Was the OS Fedora Core 1 for this bug?
>>
>> Mouss,
>> If there's a bug would you please submit it to them?
> Indeed it was.
> However, the fix was fairly straight forward. There was an entry for
> 127.0.0.1 in the /etc/resolv.conf. When that was changed to the
> interface IP, everything started working again. It's been repro'd.
> Something just doesn't like using the loopback interface for DNS
> lookups.
Thanks for the feedback Matthew. Mouss would you care to report
the bug to Fedora, if you haven't already? (It sounds like it
was somewhat known already?)
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Matthew Romanek <sh...@gmail.com>.
On Tue, 8 Feb 2005 17:34:44 -0800, Jeff Chan <je...@surbl.org> wrote:
> On Tuesday, February 8, 2005, 4:52:53 PM, mouss mouss wrote:
> > Jeff Chan wrote:
> >> On Wednesday, December 8, 2004, 8:22:24 AM, Matthew Romanek wrote:
> >>
> >>>FYI (and for future list-searchers), the problem with URIDNSBL
> >>>appearing to work but not actually scoring was because the host's
> >>>resolv.conf included 127.0.0.1, which apparently something doesn't
> >>>like.
>
> > use 0.0.0.0 instead of 127.0.0.1, or better, an IP of one of the
> > physical interfaces. there seems to be a bug with sock_dgram code.
>
> Matthew
> Was the OS Fedora Core 1 for this bug?
>
> Mouss,
> If there's a bug would you please submit it to them?
>
> Jeff C.
> --
> Jeff Chan
> mailto:jeffc@surbl.org
> http://www.surbl.org/
>
>
Indeed it was.
However, the fix was fairly straight forward. There was an entry for
127.0.0.1 in the /etc/resolv.conf. When that was changed to the
interface IP, everything started working again. It's been repro'd.
Something just doesn't like using the loopback interface for DNS
lookups.
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Jeff Chan <je...@surbl.org>.
On Tuesday, February 8, 2005, 4:52:53 PM, mouss mouss wrote:
> Jeff Chan wrote:
>> On Wednesday, December 8, 2004, 8:22:24 AM, Matthew Romanek wrote:
>>
>>>FYI (and for future list-searchers), the problem with URIDNSBL
>>>appearing to work but not actually scoring was because the host's
>>>resolv.conf included 127.0.0.1, which apparently something doesn't
>>>like.
> use 0.0.0.0 instead of 127.0.0.1, or better, an IP of one of the
> physical interfaces. there seems to be a bug with sock_dgram code.
Matthew
Was the OS Fedora Core 1 for this bug?
Mouss,
If there's a bug would you please submit it to them?
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by mouss <us...@free.fr>.
Jeff Chan wrote:
> On Wednesday, December 8, 2004, 8:22:24 AM, Matthew Romanek wrote:
>
>>FYI (and for future list-searchers), the problem with URIDNSBL
>>appearing to work but not actually scoring was because the host's
>>resolv.conf included 127.0.0.1, which apparently something doesn't
>>like.
>
>
> One possibility is that some code has 127.0.0.1 as
> a "bad" address. In particular this is one reason
> why RBLs usually don't list 127.0.0.1 as a result
> code, which could clearly break things where the
> loopback address appears in message headers, for
> example. Just a WAG for someone to check in future.
>
> Glad to hear you got things working!
>
> Jeff C.
use 0.0.0.0 instead of 127.0.0.1, or better, an IP of one of the
physical interfaces. there seems to be a bug with sock_dgram code.
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Jeff Chan <je...@surbl.org>.
On Wednesday, December 8, 2004, 8:22:24 AM, Matthew Romanek wrote:
> FYI (and for future list-searchers), the problem with URIDNSBL
> appearing to work but not actually scoring was because the host's
> resolv.conf included 127.0.0.1, which apparently something doesn't
> like.
One possibility is that some code has 127.0.0.1 as
a "bad" address. In particular this is one reason
why RBLs usually don't list 127.0.0.1 as a result
code, which could clearly break things where the
loopback address appears in message headers, for
example. Just a WAG for someone to check in future.
Glad to hear you got things working!
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Matthew Romanek <sh...@gmail.com>.
FYI (and for future list-searchers), the problem with URIDNSBL
appearing to work but not actually scoring was because the host's
resolv.conf included 127.0.0.1, which apparently something doesn't
like.
Peter Matulis just sent an unrelated email to the list mentioning
this, and after checking it out and pointing hosts at each other
instead of themselves, everything works fine. Ta-Da! Instantly my
false-negative rate dropped.
--
Matthew 'Shandower' Romanek
IDS Analyst
Re: URIDNSBL on freebsd?
Posted by Matt Barton <ma...@webexc.com>.
Jeff Chan wrote:
> Try removing from your resolv.conf:
>
> nameserver 127.0.0.1
>
> and adding some external nameservers. This may be a bug
> in the FreeBSD version of SpamAssassin.
If the DNS server on the system does listen in a regular interface, you
may be able to set the entry in resolv.conf to the IP address on that
interface (i.e. a public IP address that is local to the server).
--
Matt Barton
Webexcellence
PH: 317.423.3548 x22
TF: 800.808.6332 x22
FX: 317.423.8735
matt@webexc.com
www.webexc.com
Re: URIDNSBL on freebsd?
Posted by Theo Van Dinter <fe...@kluge.net>.
On Wed, Dec 08, 2004 at 05:05:55PM -0800, Jeff Chan wrote:
> Try removing from your resolv.conf:
> nameserver 127.0.0.1
>
> and adding some external nameservers. This may be a bug
> in the FreeBSD version of SpamAssassin.
I don't see how it's a bug in SpamAssassin. Sounds like an issue with
Net::DNS.
--
Randomly Generated Tagline:
"Engineering does not require science. Science helps a lot but people
built perfectly good brick walls long before they knew why cement works."
- Alan Cox
Re: URIDNSBL on freebsd?
Posted by Dave Goodrich <ld...@tls.net>.
Jeff Chan wrote:
> On Wednesday, December 8, 2004, 6:35:52 AM, Andrew Xiang wrote:
>
>>How to configure URIDNSBL on Freebsd? It does not seem to work by default.
>
>>-Andrew
>
> Try removing from your resolv.conf:
>
> nameserver 127.0.0.1
>
> and adding some external nameservers. This may be a bug
> in the FreeBSD version of SpamAssassin.
How is that? My spamc boxes are all FreeBSD, my spamd box is Solaris.
But, testing messages locally on my spamc boxes shows no problems. I
*only* have 127.0.0.1 in resolv.conf on all of my servers. I have each
server running DJB's dnscache on 127.0.0.1 with my DNS servers IP
addresses in the root file.
All local apps use 127.0.0.1 for DNS, and dnscache uses my DNS servers
to answer queries not in the cache. No problems. URIDNSBL works fine here.
DAve
--
Systems Administrator
http://www.tls.net
Get rid of Unwanted Emails...get TLS Spam Blocker!
Re: URIDNSBL on freebsd?
Posted by Jeff Chan <je...@surbl.org>.
On Wednesday, December 8, 2004, 6:35:52 AM, Andrew Xiang wrote:
> How to configure URIDNSBL on Freebsd? It does not seem to work by default.
> -Andrew
Try removing from your resolv.conf:
nameserver 127.0.0.1
and adding some external nameservers. This may be a bug
in the FreeBSD version of SpamAssassin.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
URIDNSBL on freebsd?
Posted by Andrew Xiang <xi...@gratingworks.com>.
How to configure URIDNSBL on Freebsd? It does not seem to work by default.
-Andrew
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Matthew Romanek <sh...@gmail.com>.
> t/dnsbl.....................Bareword found in conditional at t/dnsbl.t line 15.
> Not found: P_2 =
> <dns:134.88.73.210.dnsbltest.spamassassin.org> [127.0.0.4]
> # Failed test 1 in t/SATest.pm at line 530
> Not found: P_7 =
> <dns:134.88.73.210.sb.dnsbltest.spamassassin.org?type=TXT>
> # Failed test 2 in t/SATest.pm at line 530 fail #2
> Not found: P_4 =
> <dns:14.35.17.212.dnsbltest.spamassassin.org> [127.0.0.1, 127.0.0.1]
> # Failed test 3 in t/SATest.pm at line 530 fail #3
> Not found: P_3 =
> <dns:18.13.119.61.dnsbltest.spamassassin.org> [127.0.0.12]
> # Failed test 4 in t/SATest.pm at line 530 fail #4
> Not found: P_5 =
> <dns:226.149.120.193.dnsbltest.spamassassin.org> [127.0.0.1]
> # Failed test 5 in t/SATest.pm at line 530 fail #5
> Not found: P_1 =
> <dns:98.3.137.144.dnsbltest.spamassassin.org> [127.0.0.2]
> # Failed test 6 in t/SATest.pm at line 530 fail #6
> Not found: P_6 = <dns:example.com.dnsbltest.spamassassin.org>
> [127.0.0.2]
> # Failed test 7 in t/SATest.pm at line 530 fail #7
> Not found: P_15 = DNSBL_RHS
> # Failed test 8 in t/SATest.pm at line 530 fail #8
> Not found: P_17 = DNSBL_SB_FLOAT
> # Failed test 9 in t/SATest.pm at line 530 fail #9
> Not found: P_18 = DNSBL_SB_STR
> # Failed test 10 in t/SATest.pm at line 530 fail #10
> Not found: P_16 = DNSBL_SB_TIME
> # Failed test 11 in t/SATest.pm at line 530 fail #11
> Not found: P_10 = DNSBL_TEST_DYNAMIC
> # Failed test 12 in t/SATest.pm at line 530 fail #12
> Not found: P_12 = DNSBL_TEST_RELAY
> # Failed test 13 in t/SATest.pm at line 530 fail #13
> Not found: P_11 = DNSBL_TEST_SPAM
> # Failed test 14 in t/SATest.pm at line 530 fail #14
> Not found: P_8 = DNSBL_TEST_TOP
> # Failed test 15 in t/SATest.pm at line 530 fail #15
> Not found: P_9 = DNSBL_TEST_WHITELIST
> # Failed test 16 in t/SATest.pm at line 530 fail #16
> Not found: P_14 = DNSBL_TXT_RE
> # Failed test 17 in t/SATest.pm at line 530 fail #17
> Not found: P_13 = DNSBL_TXT_TOP
> # Failed test 18 in t/SATest.pm at line 530 fail #18
> t/dnsbl.....................FAILED tests 1-18
> Failed 18/22 tests, 18.18% okay
I did some looking, and came up with a previous thread about this at:
http://archive.netbsd.se/?ml=spamassassin-users&a=2004-08&t=282748
The resolution here was to update Net::DNS. Obviously, I've done that,
as well as making sure Digest::SHA1 was in, and still I get these
errors. On the perl side, is there anything I need to do to make sure
they're working? CPAN says the latest versions are installed (I made
doubly sure by manualling installing Net::DNS by hand), but it's just
not working.
Any pointers for where to look for more specific error messages would
be appreciated, as well. I don't know why theses are failing, they
just are.
To recap, DNSBL worked when I ran 2.6. After I up'd to 3.0.1, they
stopped working. SA -D reported timeouts at 15 seconds. I upped it to
30 seconds, and now it says 'complete' at 17 seconds, but still does
not mark up messages that it should.
Thanks!
--
Matthew 'Shandower' Romanek
IDS Analyst
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Matthew Romanek <sh...@gmail.com>.
> > # vi /usr/share/spamassassin/25_uribl.cf
> Is this the right directory, anyone?
All the other rules in there are working, including Bayes and pattern
matching. Since SURBL is showing up in the debug, it's obviously
getting the cue from somewhere..
> Do you have non-zero scores set?
Indeed. That was my first thought, so I made a local config change to
use the one-score variety, just in case something wierd was going on.
No change.
In a fit of aggrivation, I downloaded a fresh copy of the SA tar file,
unpacked it, and started to install it. I happened to think to run
make test, though, and found THIS:
t/dnsbl.....................Bareword found in conditional at t/dnsbl.t line 15.
Not found: P_2 =
<dns:134.88.73.210.dnsbltest.spamassassin.org> [127.0.0.4]
# Failed test 1 in t/SATest.pm at line 530
Not found: P_7 =
<dns:134.88.73.210.sb.dnsbltest.spamassassin.org?type=TXT>
# Failed test 2 in t/SATest.pm at line 530 fail #2
Not found: P_4 =
<dns:14.35.17.212.dnsbltest.spamassassin.org> [127.0.0.1, 127.0.0.1]
# Failed test 3 in t/SATest.pm at line 530 fail #3
Not found: P_3 =
<dns:18.13.119.61.dnsbltest.spamassassin.org> [127.0.0.12]
# Failed test 4 in t/SATest.pm at line 530 fail #4
Not found: P_5 =
<dns:226.149.120.193.dnsbltest.spamassassin.org> [127.0.0.1]
# Failed test 5 in t/SATest.pm at line 530 fail #5
Not found: P_1 =
<dns:98.3.137.144.dnsbltest.spamassassin.org> [127.0.0.2]
# Failed test 6 in t/SATest.pm at line 530 fail #6
Not found: P_6 = <dns:example.com.dnsbltest.spamassassin.org>
[127.0.0.2]
# Failed test 7 in t/SATest.pm at line 530 fail #7
Not found: P_15 = DNSBL_RHS
# Failed test 8 in t/SATest.pm at line 530 fail #8
Not found: P_17 = DNSBL_SB_FLOAT
# Failed test 9 in t/SATest.pm at line 530 fail #9
Not found: P_18 = DNSBL_SB_STR
# Failed test 10 in t/SATest.pm at line 530 fail #10
Not found: P_16 = DNSBL_SB_TIME
# Failed test 11 in t/SATest.pm at line 530 fail #11
Not found: P_10 = DNSBL_TEST_DYNAMIC
# Failed test 12 in t/SATest.pm at line 530 fail #12
Not found: P_12 = DNSBL_TEST_RELAY
# Failed test 13 in t/SATest.pm at line 530 fail #13
Not found: P_11 = DNSBL_TEST_SPAM
# Failed test 14 in t/SATest.pm at line 530 fail #14
Not found: P_8 = DNSBL_TEST_TOP
# Failed test 15 in t/SATest.pm at line 530 fail #15
Not found: P_9 = DNSBL_TEST_WHITELIST
# Failed test 16 in t/SATest.pm at line 530 fail #16
Not found: P_14 = DNSBL_TXT_RE
# Failed test 17 in t/SATest.pm at line 530 fail #17
Not found: P_13 = DNSBL_TXT_TOP
# Failed test 18 in t/SATest.pm at line 530 fail #18
t/dnsbl.....................FAILED tests 1-18
Failed 18/22 tests, 18.18% okay
Either it's an amazing coincidence, or this has something to do with
the reason the DNSBL's aren't working for me. So my next question,
knowing next to nothing about perl, is what is this actually showing
me? This is a fresh package I got, with no changes what-so-ever.
On a whim, I did the same thing with Net::DNS, since there was some
question as to what version was involved. It went in fine, but made no
difference to these tests.
Note that only 18 of the tests failed. P_1, 3, 4, 5 and 6 seemed to work?
--
Matthew 'Shandower' Romanek
IDS Analyst
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Jeff Chan <je...@surbl.org>.
On Tuesday, December 7, 2004, 6:31:41 AM, Matthew Romanek wrote:
>> Are you sure you're using 3.0.1 configs?
> Pretty sure:
> # spamassassin -V
> SpamAssassin version 3.0.1
> running on Perl version 5.8.1
> # vi /usr/share/spamassassin/25_uribl.cf
Is this the right directory, anyone?
> uridnsbl URIBL_SBL sbl.spamhaus.org. TXT
> body URIBL_SBL eval:check_uridnsbl('URIBL_SBL')
> describe URIBL_SBL Contains an URL listed in the SBL blocklist
> tflags URIBL_SBL net
> urirhssub URIBL_SC_SURBL multi.surbl.org. A 2
> body URIBL_SC_SURBL eval:check_uridnsbl('URIBL_SC_SURBL')
> describe URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
> tflags URIBL_SC_SURBL net
> ...
Do you have non-zero scores set?
That's about the limit of my debugging knowledge for SA,
so hopefully someone else can help out.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Matthew Romanek <sh...@gmail.com>.
> 17 seconds is way too long for name resolution. Does it take
> that long from the command line (for an uncached query)?
No, it's pretty snappy all around. But with a 15 second timeout,
spamassassin -D showed all timeouts for the DNSBL. The URIBL's
appeared to have successful queries even at that point, but I can't
get them to actually score against anything. I'm not sure what the
difference between them (at the lookup level) is.
# time dig test.surbl.org.sc.surbl.org a | less
; <<>> DiG 9.2.2-P3 <<>> test.surbl.org.sc.surbl.org a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29925
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 14, ADDITIONAL: 0
;; QUESTION SECTION:
;test.surbl.org.sc.surbl.org. IN A
;; ANSWER SECTION:
test.surbl.org.sc.surbl.org. 2023 IN A 127.0.0.2
;; AUTHORITY SECTION:
sc.surbl.org. 823 IN NS n.surbl.org.
sc.surbl.org. 823 IN NS a.surbl.org.
sc.surbl.org. 823 IN NS b.surbl.org.
sc.surbl.org. 823 IN NS c.surbl.org.
sc.surbl.org. 823 IN NS d.surbl.org.
sc.surbl.org. 823 IN NS e.surbl.org.
sc.surbl.org. 823 IN NS f.surbl.org.
sc.surbl.org. 823 IN NS g.surbl.org.
sc.surbl.org. 823 IN NS h.surbl.org.
sc.surbl.org. 823 IN NS i.surbl.org.
sc.surbl.org. 823 IN NS j.surbl.org.
sc.surbl.org. 823 IN NS k.surbl.org.
sc.surbl.org. 823 IN NS l.surbl.org.
sc.surbl.org. 823 IN NS m.surbl.org.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Dec 7 06:09:17 2004
;; MSG SIZE rcvd: 285
real 0m1.030s
user 0m0.010s
sys 0m0.010s
> Are you sure you're using 3.0.1 configs?
Pretty sure:
# spamassassin -V
SpamAssassin version 3.0.1
running on Perl version 5.8.1
# vi /usr/share/spamassassin/25_uribl.cf
...
uridnsbl URIBL_SBL sbl.spamhaus.org. TXT
body URIBL_SBL eval:check_uridnsbl('URIBL_SBL')
describe URIBL_SBL Contains an URL listed in the SBL blocklist
tflags URIBL_SBL net
urirhssub URIBL_SC_SURBL multi.surbl.org. A 2
body URIBL_SC_SURBL eval:check_uridnsbl('URIBL_SC_SURBL')
describe URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
tflags URIBL_SC_SURBL net
...
> IIRC one of the recent FreeBSD installations had the 3.0.1
> config file going to the wrong directory for some reason.
> It should be in the recent list archives.
This is on Fedora Core 1, updated via CPAN if I remember right.
I appreciate the help, too. Let me know if there's any other
information I can get for you. Thanks!
--
Matthew 'Shandower' Romanek
IDS Analyst
Re: [SPAM-TAG] Further URIDNSBL problems..
Posted by Jeff Chan <je...@surbl.org>.
On Monday, December 6, 2004, 8:27:58 AM, Matthew Romanek wrote:
> Okay, after my last post, I had the amazingly bright idea to feed
> spamd some mail in debug mode. It showed pretty clearly that all the
> DNS lookups were timing out at 15 seconds. I increased the timeout to
> 30, and now things are resolving at 17 seconds. Duh.
17 seconds is way too long for name resolution. Does it take
that long from the command line (for an uncached query)?
% time dig test.surbl.org.sc.surbl.org a
; <<>> DiG 8.3 <<>> test.surbl.org.sc.surbl.org a
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35541
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 14, ADDITIONAL: 14
;; QUERY SECTION:
;; test.surbl.org.sc.surbl.org, type = A, class = IN
;; ANSWER SECTION:
test.surbl.org.sc.surbl.org. 1W IN A 127.0.0.2
;; AUTHORITY SECTION:
sc.surbl.org. 15M IN NS b.surbl.org.
[...]
;; Total query time: 7 msec
;; FROM: ns1.freeapp.net to SERVER: 127.0.0.1
;; WHEN: Mon Dec 6 23:55:26 2004
;; MSG SIZE sent: 45 rcvd: 509
0.003u 0.000s 0:00.01 0.0% 0+0k 0+0io 0pf+0w
% time dig test.surbl.org.ws.surbl.org a
; <<>> DiG 8.3 <<>> test.surbl.org.ws.surbl.org a
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37008
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 14, ADDITIONAL: 14
;; QUERY SECTION:
;; test.surbl.org.ws.surbl.org, type = A, class = IN
;; ANSWER SECTION:
test.surbl.org.ws.surbl.org. 1W IN A 127.0.0.2
[...]
;; Total query time: 2 msec
;; FROM: ns1.freeapp.net to SERVER: 127.0.0.1
;; WHEN: Mon Dec 6 23:57:05 2004
;; MSG SIZE sent: 45 rcvd: 509
0.000u 0.003s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
> The RBLs worked fine on 2.6, but haven't been working since
> going to 3.0.1.
Are you sure you're using 3.0.1 configs?
IIRC one of the recent FreeBSD installations had the 3.0.1
config file going to the wrong directory for some reason.
It should be in the recent list archives.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/