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
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
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:
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
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.
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
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
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
> 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
> 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
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
> 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
> 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
> > # 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
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
> 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
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
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 g
18 matches
Mail list logo
