Re: [SPAM-TAG] Further URIDNSBL problems..

2005-02-09 Thread Kelson
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

Re: [SPAM-TAG] Further URIDNSBL problems..

2005-02-09 Thread mouss
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/gr

Re: [SPAM-TAG] Further URIDNSBL problems..

2005-02-09 Thread Jeff Chan
On Tuesday, February 8, 2005, 10:27:21 PM, Matthew Romanek wrote: > On Tue, 8 Feb 2005 17:34:44 -0800, Jeff Chan <[EMAIL PROTECTED]> 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:

Re: [SPAM-TAG] Further URIDNSBL problems..

2005-02-09 Thread Matthew Romanek
On Tue, 8 Feb 2005 17:34:44 -0800, Jeff Chan <[EMAIL PROTECTED]> 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 URIDNSB

Re: [SPAM-TAG] Further URIDNSBL problems..

2005-02-09 Thread Jeff Chan
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.

Re: [SPAM-TAG] Further URIDNSBL problems..

2005-02-09 Thread Matt Kettler
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 bette

Re: [SPAM-TAG] Further URIDNSBL problems..

2005-02-09 Thread mouss
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 possibil

Re: [SPAM-TAG] Further URIDNSBL problems..

2004-12-09 Thread Jeff Chan
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 th

Re: [SPAM-TAG] Further URIDNSBL problems..

2004-12-08 Thread Matthew Romanek
> I find it pretty hard to believe it couldn't resolve off itself. Have > you checked your firewall rules, and your named.conf to see if you've > allowed-query 127.0.0.1 in your options statement? Have you tried > resolving anything locally, while ssh'ed into the box? What about using > another

RE: [SPAM-TAG] Further URIDNSBL problems..

2004-12-08 Thread Jon Dossey
> 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. I find it pretty hard to believe it couldn't resolve off itself. Have you checked your

Re: [SPAM-TAG] Further URIDNSBL problems..

2004-12-08 Thread Matthew Romanek
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 ou

Re: [SPAM-TAG] Further URIDNSBL problems..

2004-12-08 Thread Matthew Romanek
> t/dnsbl.Bareword found in conditional at t/dnsbl.t line > 15. > Not found: P_2 = > [127.0.0.4] > # Failed test 1 in t/SATest.pm at line 530 > Not found: P_7 = > > # Failed test 2 in t/SATest.pm at line 530 fail #2 > Not found: P_4 = > [127.0.0.1, 12

Re: [SPAM-TAG] Further URIDNSBL problems..

2004-12-07 Thread Matthew Romanek
> 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..

2004-12-07 Thread Matthew Romanek
> > # 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. T

Re: [SPAM-TAG] Further URIDNSBL problems..

2004-12-07 Thread Jeff Chan
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? > uridns

Re: [SPAM-TAG] Further URIDNSBL problems..

2004-12-07 Thread Matthew Romanek
> 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 tha

Re: [SPAM-TAG] Further URIDNSBL problems..

2004-12-07 Thread Jeff Chan
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