--On Wednesday, December 16, 2015 6:28 PM +0100 Mark Martinec
wrote:
Tried it now with 3.4.1 and Net::DNS 1.04.
You still need to apply the patch from Bug 7223 (in addition
to a patch from Bug 7231), then it passes all tests with
Net::DNS 1.04 (even without patches from Bug 7265).
Seems
Not sure about SPF. It's supposed to be fixed in the current 3.4 branch
and in trunk, which is why I'm not seeing a problem with Net::DNS 1.03
or Net::DNS 1.04. Will check how the released version of 3.4.1 fares
with Net::DNS 1.04 regarding SPF. The emergency patches were applied
to Fre
. Regards,
KAM
Downgrade? I upgraded to 1.04: does that not fix the problem?
you answered that question at your own by only get SPF_NONE
A fair point! Is anyone else seeing the same problem?
As noted by Mark, there were changes for Net::DNS 1.01 and later that must
be applied to SA 3.4.1 if
Ian Eiloart wrote:
I had this problem after upgrading from a rather old version of SA.
After
upgrading to Net::DNS 1.04, the errors aren’t logged, but SpamAssassin
isn’t
finding SPF records. I wonder whether anyone can offer any suggestions.
[...]
Yesterday, I upgraded Net::DNS 1.03 to Net
might work ok but
Net::DNS changed things in 1.03 and then reverted but unsure if that's
what you are hitting.
See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7265
I would recommend an older Net::DNS and see if things work.
Regards,
KAM
On Wed, 16 Dec 2015 16:13:03 -, Ian Eiloart wrote:
On 16 Dec 2015, at 16:09, Reindl Harald wrote:
Am 16.12.2015 um 17:00 schrieb Ian Eiloart:
On 16 Dec 2015, at 15:30, Kevin A. McGrail wrote:
Downgrade tour netdns. There were changes in 1.03 that are fixed in
trunk.
Regards,
K
> On 16 Dec 2015, at 16:09, Reindl Harald wrote:
>
>
>
> Am 16.12.2015 um 17:00 schrieb Ian Eiloart:
>>
>>> On 16 Dec 2015, at 15:30, Kevin A. McGrail wrote:
>>>
>>> Downgrade tour netdns. There were changes in 1.03 that are fixed in trunk.
>>> Regards,
>>> KAM
>>
>> Downgrade? I upgraded
only get SPF_NONE
Weitergeleitete Nachricht
Betreff: Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03
Datum: Wed, 16 Dec 2015 14:49:38 +
Von: Ian Eiloart
An: users@spamassassin.apache.org
Hi,
I had this problem after upgrading from a rather old version of SA
> On 16 Dec 2015, at 15:30, Kevin A. McGrail wrote:
>
> Downgrade tour netdns. There were changes in 1.03 that are fixed in trunk.
> Regards,
> KAM
Downgrade? I upgraded to 1.04: does that not fix the problem?
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
Downgrade tour netdns. There were changes in 1.03 that are fixed in trunk.
Regards,
KAM
On December 16, 2015 9:49:38 AM EST, Ian Eiloart wrote:
>Hi,
>
>I had this problem after upgrading from a rather old version of SA.
>After upgrading to Net::DNS 1.04, the errors aren’t
Hi,
I had this problem after upgrading from a rather old version of SA. After
upgrading to Net::DNS 1.04, the errors aren’t logged, but SpamAssassin isn’t
finding SPF records. I wonder whether anyone can offer any suggestions.
I’m calling spamd from Exim.
/opt/local/bin/spamd --version
--On Wednesday, December 09, 2015 1:27 PM -0800 Quanah Gibson-Mount
wrote:
In testing in my lab, I've found significant issues using SpamAssassin
3.4.1 with Net::DNS 1.02 or later. Previously, I was using 0.81.
This appears to be <https://bz.apache.org/SpamAssassin/show_bug.cgi
In testing in my lab, I've found significant issues using SpamAssassin
3.4.1 with Net::DNS 1.02 or later. Previously, I was using 0.81.
With Net::DNS 1.02 or 1.04, there is an 15 second+ delay in delivering
email. With debugging enabled for SA, we see the first delay here:
Dec 9 15:
02 -> 1.03 update.
+1. An API change in a minor rev is not acceptable.
Net::DNS 1.04 is out, fixing these issues. So far, it works better for
me than 1.20 or 1.30 did in my lab.
Err, 1.02 and 1.03. ;)
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
Z
--On Friday, November 13, 2015 2:01 PM -0500 "Kevin A. McGrail"
wrote:
On 11/13/2015 2:00 PM, Mark Martinec wrote:
To me, this is an incompatible documented change - not something
one would expect in an 1.02 -> 1.03 update.
+1. An API change in a minor rev is not acceptabl
On 11/13/2015 2:00 PM, Mark Martinec wrote:
To me, this is an incompatible documented change - not something
one would expect in an 1.02 -> 1.03 update.
+1. An API change in a minor rev is not acceptable.
--
*Kevin A. McGrail*
CEO
Peregrine Computer Consultants Corporation
3927 Old Lee Highw
Net::DNS 1.03 breaks compatibility with SpamAssassin:
DNS lookups no longer work, and warnings like the following pop up:
On 2015-11-13 19:22, Quanah Gibson-Mount wrote:
Well, IO::Socket::IP support is new in Net::DNS 1.03, but it is only
used if IO::Socket::INET6 is not present. I would
--On Friday, November 13, 2015 10:22 AM -0800 Quanah Gibson-Mount
wrote:
Well, IO::Socket::IP support is new in Net::DNS 1.03, but it is only used
if IO::Socket::INET6 is not present. I would assume you can use it as
long as you have IO::Socket::INET6 installed, but I haven't tested
--On Friday, November 13, 2015 1:20 AM +0100 Mark Martinec
wrote:
Net::DNS 1.03 breaks compatibility with SpamAssassin:
DNS lookups no longer work, and warnings like the following pop up:
lookup failed: Can't locate object method "handles" via package
"IO::Socket::IP
Net::DNS 1.03 breaks compatibility with SpamAssassin:
DNS lookups no longer work, and warnings like the following pop up:
lookup failed: Can't locate object method "handles" via package
"IO::Socket::IP"
at /usr/local/lib/perl5/site_perl/Net/DNS/Resolver/Base.pm l
>
> Your problem is URIBL_BLOCKED. The usual cause of this is running a mail
> system that relies on a public-access DNS resolver, although if you have
> substantial volume on your system you can have this happen with your own DNS
> infrastructure. See http://uribl.com/refused.shtml for detail
::dns is also have the same problem
Nope. The Net::DNS problem is a >1.0 issue only and causes SA to ask DNS
questions in a way that resolvers to respond with empty non-failure
replies to questions about names that they would need to recurse in
order to resolve. URIBL_BLOCKED is triggered b
sired"
flag. Since my local nameservers isn't authoritative for much, this
meant a whole lot of "no answer, no error" DNS replies.
I have 3.4.0 and have noticed this as well. But my NetDNS is 0.78
Not the same root cause then. But read on...
module installed: Net::DNS,
,
URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
you ARE blocked
good or bad does matter ?
that means you wast dns resources on uribl.com just to see you are
blocked, and not getting anything in return on it, that sayed i think
your net::dns is also have the same problem
rsion
desired" flag. Since my local nameservers isn't authoritative for much, this meant a whole lot
of "no answer, no error" DNS replies.
I have 3.4.0 and have noticed this as well. But my NetDNS is 0.78
module installed: Net::DNS, version 0.78
everything installed from apt on u
. Since my local nameservers
> isn't authoritative for much, this meant a whole lot of "no answer, no error"
> DNS replies.
I have 3.4.0 and have noticed this as well. But my NetDNS is 0.78
module installed: Net::DNS, version 0.78
everything installed from apt on ubuntu utopic 14
Not to forget the fix at:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202283
which is also needed with Net::DNS 1.01 or later.
Sorry, wrong link, should be:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7231
Already cherrypicked in the FreeBSD port of SpamAssassin:
https
it down to SA making DNS queries without the
"recursion desired" flag. Since my local nameservers isn't
authoritative
for much, this meant a whole lot of "no answer, no error" DNS replies.
It turns out that this is due to an internal change introduced in
recent
versions o
down to SA making DNS queries without the
> "recursion desired" flag. Since my local nameservers isn't authoritative
> for much, this meant a whole lot of "no answer, no error" DNS replies.
>
> It turns out that this is due to an internal change introduced in rece
rsion desired" flag. Since my local nameservers isn't authoritative
for much, this meant a whole lot of "no answer, no error" DNS replies.
It turns out that this is due to an internal change introduced in recent
versions of Net::DNS, which SA relied upon to set the RD flag
BTW: https://rt.cpan.org/Public/Bug/Display.html?id=55278
On Fri, Mar 5, 2010 at 16:46, Mark Martinec wrote:
> Your options are:
> - contact the maintainer of IO::Socket::INET6 and sort out the problem;
I just did and filed a bug report. Let's hope they can treat
127.0.0.1/0.0.0.0 as special cases and NOT query them against local
domain.
No one but ins
myself wrote:
> - contact the maintainer of IO::Socket::INET6 and sort out the problem;
> - avoid mapping 127.0.0.1 query into an IPv6 address of your
> nonrecursive DNS server.
> (preferably both).
Actually there are more options:
- allow your IPv6 DNS server to answer recursive queries fr
194: );
Since getaddrinfo is told to try AF_INET6 first but is given 127.0.0.1
as $raddr, it decides it is not an IPv6 address, and tries to resolve it!
Instead of receiving a usual NXDOMAIN, you are supplying it with an
address 2002:4e2e:3890::1, letting all hell break loose from here on.
I don&
> Forgot option -n, makes it unknown whether 'localhost' is 127.0.0.1 or ::1.
13:57:40.287618 IP (tos 0x0, ttl 64, id 30469, offset 0, flags [none],
proto UDP (17), length 66, bad cksum 0 (->5a4)!)
127.0.0.1.36192 > 127.0.0.1.53: [udp sum ok] 45090+ A?
marvin.luigilauro.it. (38)
13:57:40.28781
Luigi,
> marvin% perl -le 'use IO::Socket::INET6; print IO::Socket::INET6->VERSION'
> 2.57
Good.
> > Try capturing your traffic on a loopback interface for port 53:
>
> This is the output with -vv for protocol decode with my recursive
> local DNS on 127.0.0.1 and my authorative DNS on listening
> Weird indeed. Which version of IO::Socket::INET6 do you have?
marvin% perl -le 'use IO::Socket::INET6; print IO::Socket::INET6->VERSION'
2.57
> Try capturing your traffic on a loopback interface for port 53:
This is the output with -vv for protocol decode with my recursive
local DNS on 127.0.
Luigi,
> Mar 4 21:14:52.177 [4180] dbg: dns: no packet! err=Connection refused
> packet=undef
> Mar 4 21:14:55.196 [4180] dbg: dns: NS lookup of apache.org using
> 127.0.0.1 failed, no results found
Weird indeed. Which version of IO::Socket::INET6 do you have?
$ perl -le 'use IO::Socket::INET6
/libexec/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin
Mar 4 20:58:03.725 [2784] dbg: dns: is Net::DNS::Resolver available? yes
Mar 4 20:58:03.725 [2784] dbg: dns: Net::DNS version: 0.66
Mar 4 20:58:03.725 [2784] dbg: config: using
"/usr/local/etc/mail/spa
:52.175 [4180] dbg: dns: is Net::DNS::Resolver available? yes
Mar 4 21:14:52.175 [4180] dbg: dns: Net::DNS version: 0.66
Mar 4 21:14:52.176 [4180] dbg: dns: name server: 127.0.0.1, LocalAddr: 0.0.0.0
Mar 4 21:14:52.176 [4180] dbg: dns: resolver socket rx buffer size is
42080 bytes
Mar 4 21:14
/libexec/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin
Mar 4 20:58:03.725 [2784] dbg: dns: is Net::DNS::Resolver available? yes
Mar 4 20:58:03.725 [2784] dbg: dns: Net::DNS version: 0.66
Mar 4 20:58:03.725 [2784] dbg: config: using
"/usr/local/etc/mail/spa
On Thu, 2 Jul 2009, Per Jessen wrote:
1) a tiny perl test-script using gethostbyname() will look at /etc/hosts
and try to resolve the name from there. Works fine and just as
expected.
2) a call to gethostbyname() from within an SA plugin does NOT look
at /etc/hosts.
When in doubt, blame permiss
Henrik K wrote:
> On Thu, Jul 02, 2009 at 10:08:31AM +0200, Per Jessen wrote:
>>
>> Now for calling gethostbyname() from within SA - I could share the
>> plugin code, but it won't work without a few other things, so if you
>> can think of another/easier way of calling gethostbyname() from
>> with
On Thu, Jul 02, 2009 at 10:08:31AM +0200, Per Jessen wrote:
>
> Now for calling gethostbyname() from within SA - I could share the
> plugin code, but it won't work without a few other things, so if you
> can think of another/easier way of calling gethostbyname() from within
> SA, then you'll see t
Henrik K wrote:
> On Thu, Jul 02, 2009 at 09:10:54AM +0200, Per Jessen wrote:
>>
>> Here it is in a nutshell:
>>
>> 1) a tiny perl test-script using gethostbyname() will look at
>> /etc/hosts and try to resolve the name from there. Works fine and
>> just as expected.
>>
>> 2) a call to gethostb
On Thu, Jul 02, 2009 at 09:10:54AM +0200, Per Jessen wrote:
> René Berber wrote:
>
> > On many operating systems (Solaris, Fedora 11, and Gentoo Linux are
> > the ones I have) the file /etc/nsswitch.conf controls exactly what you
> > are asking, the usual relevant line is:
> >
> > hosts: fi
tiny perl test-script using gethostbyname() will look at /etc/hosts
and try to resolve the name from there. Works fine and just as
expected.
2) a call to gethostbyname() from within an SA plugin does NOT look
at /etc/hosts.
I've tried just instantiating Net::DNS::Resolver in my test-script, bu
Per Jessen wrote:
> Theo Van Dinter wrote:
>
>> On Wed, Jul 1, 2009 at 3:23 AM, Per Jessen wrote:
>>> Back to the subject line - how do I make Net::DNS::Resolver
>>> take /etc/hosts into account?
>> b) my guess is that you can't, but it's a questio
Theo Van Dinter wrote:
> On Wed, Jul 1, 2009 at 3:23 AM, Per Jessen wrote:
>> Back to the subject line - how do I make Net::DNS::Resolver
>> take /etc/hosts into account?
>
> b) my guess is that you can't, but it's a question for the Net::DNS
> folks, not SA
On Wed, Jul 1, 2009 at 3:23 AM, Per Jessen wrote:
> Back to the subject line - how do I make Net::DNS::Resolver
> take /etc/hosts into account?
a) of course it doesn't, /etc/hosts isn't DNS, so why would Net::DNS
look at it? :)
b) my guess is that you can't, but it's a
Per Jessen wrote:
> All,
>
> for whatever reason, Net::DNS::Resolver (as used in SA) doesn't appear
Sorry, wrong list.
/Per Jessen, Zürich
All,
for whatever reason, Net::DNS::Resolver (as used in SA) doesn't appear
to look at /etc/hosts. I thought it was a Net::DNS::Resolver
peculiarity, maybe something to do with cross-platform support, so in
a plugin module I've been writing, I tried to gethostbyname() instead.
I v
ackup fixed the
issue.
HTH
Cheers,
Michael Hutchinson
-Original Message-
From: mouss [mailto:mo...@ml.netoyen.net]
Sent: Thursday, 22 January 2009 9:40 a.m.
To: users@spamassassin.apache.org
Subject: Re: Can't locate object method "new" via package "Net::DNS::RR::TXT&qu
Brian J. Murrell a écrit :
> I seem to be getting a lot of these in the last 36h:
>
>
> 12:02:26 spamd Can't locate object method "new" via package
> "Net::DNS::RR::TXT" at /usr/lib/perl5/Net/DNS/RR.pm line 305.
> 12:02:26 spamd caught at /usr/s
I seem to be getting a lot of these in the last 36h:
12:02:26 spamd Can't locate object method "new" via package "Net::DNS::RR::TXT"
at /usr/lib/perl5/Net/DNS/RR.pm line 305.
12:02:26 spamd caught at /usr/share/perl5/Mail/SpamAssassin/DnsResolver.pm line
419
Any ideas why?
b.
You are correct Thank you!
Karsten Bräckelmann-2 wrote:
>
> On Sun, 2009-01-18 at 13:20 -0800, K9Barry wrote:
>> Using spamassassin v 3.2.3 on a Debian Linux 4.0
>>
>> When I run spamassassin --lint it runs properly and returnd (blank) no
>> errors.
>>
>> When I run spamassassin -D I get this
On Sun, 2009-01-18 at 13:20 -0800, K9Barry wrote:
> Using spamassassin v 3.2.3 on a Debian Linux 4.0
>
> When I run spamassassin --lint it runs properly and returnd (blank) no
> errors.
>
> When I run spamassassin -D I get this (see below) and the terminal hangs.
>
> # /usr/bin/spamassassin -D
bin', keeping
[5402] dbg: util: PATH included '/usr/bin/X11', keeping
[5402] dbg: util: final PATH set to:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
[5402] dbg: dns: is Net::DNS::Resolver available? yes
[5402] dbg: dns: Net::DNS version: 0.63
Can someon
Michael Scheidell wrote:
From:
http://search.cpan.org/src/OLAF/Net-DNS-0.63/Changes
Fix rt.cpan.org #30316 Security issue with Net::DNS Resolver.
Net/DNS/RR/A.pm in Net::DNS 0.60 build 654 allows remote attackers
to cause a denial of service (program "croak") via a crafted DNS
Justin Mason wrote:
This issue has no security impact. The flaw will cause Net::DNS to
"croak", which in turn should be handled by the calling application. In
the case of RHEL, the only known application that uses this
functionality is Spamassassin. Spamassassin handles th
Michael Scheidell writes:
> From:
> http://search.cpan.org/src/OLAF/Net-DNS-0.63/Changes
>
> Fix rt.cpan.org #30316 Security issue with Net::DNS Resolver.
>
> Net/DNS/RR/A.pm in Net::DNS 0.60 build 654 allows remote attackers to
> cause a denial of service (program &
From:
http://search.cpan.org/src/OLAF/Net-DNS-0.63/Changes
Fix rt.cpan.org #30316 Security issue with Net::DNS Resolver.
Net/DNS/RR/A.pm in Net::DNS 0.60 build 654 allows remote attackers to
cause a denial of service (program "croak") via a crafted DNS
response (http://nvd.nist.g
On Sat, October 13, 2007 14:11, mouss wrote:
>...
> maybe a chroot problem?
>...
Thank you for the tip. Actually it was something alike: the directory where
PTR.pm is
was accessible only by root.
), SpamAssassin and other products like Clamav and
Squirrel Mail.
>> error: Can't locate Net/DNS/RR/PTR.pm in @INC (@INC contains: ../lib
>> ...
>> I have checked that Net/DNS/RR/PTR.pm exists in
>> /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi (one of th
oaster related to SpamAssassin?
> error: Can't locate Net/DNS/RR/PTR.pm in @INC (@INC contains: ../lib
> ...
> I have checked that Net/DNS/RR/PTR.pm exists in
> /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi (one of the
> directories in @INC), so I can't figure
d
> processes thousands of emails daily, rejecting many of them of spam
> and marking others as such.
>
> However, the logs os SA (in /var/log/qmail/spamd) show plenty of the
> following error:
>
> error: Can't locate Net/DNS/RR/PTR.pm in @INC (@INC contains: ../lib
> /us
them of spam and marking others
as such.
However, the logs os SA (in /var/log/qmail/spamd) show plenty of the following
error:
error: Can't locate Net/DNS/RR/PTR.pm in @INC (@INC contains: ../lib
/usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.
Hello,
I hope I'm doing this right. I'm trying to install an SA required
module, Net::DNS, and it fails one of the tests.
Running "make test" I see the following:
t/10-recurse...1..12
ok 1 - use Net::DNS::Resolver::Recurse;
ok 2 - The object isa Net::DNS::Re
Michael Scheidell wrote:
Don't know if anyone has mentioned this, if so, I missed it.
Potential DOS in spamassassin if perl-Net-DNS < .60. (previously
recommended version was .58)
Freebsd ports has .60, for the last two weeks.
Thanks for the FYI.
MrC
-Original Message-
Fro
Don't know if anyone has mentioned this, if so, I missed it.
Potential DOS in spamassassin if perl-Net-DNS < .60. (previously
recommended version was .58)
Freebsd ports has .60, for the last two weeks.
-Original Message-
From: rPath Update Announcements [mailto:[EMAIL PROTECTE
On Wed, 1 Nov 2006 08:58:26 +0100, [EMAIL PROTECTED] wrote:
>It? possible on perl version 5.8.1 install the Net::DNS?
> [EMAIL PROTECTED]
> mailto:[EMAIL PROTECTED]
CPAN is the usual way to do it, tho iirc that has caused some problems
(it did here). I got round it by installing through
Itś possible on perl version 5.8.1 install the Net::DNS?
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
I have SpamAssassin-3.1.7 with Postfix MTA on
RHEL 3.0.
I have found following failure message in my
postfix log file. I believe that problem is happened when i updated
Net::DNS perl module from CPAN. Yet SpamAssassin is working perfectly with
postfix MTA without any problem
Oct 23 11
On Fri, Oct 06, 2006 at 06:15:01PM +0200, Thomas Ericsson wrote:
> Net::DNS, restarted SA. URIBL rules starting to hit, jipe! Still
> som eproblems running sa-update though. Seems like i'm missing some
> perl modules:
>
> admin# ./sa-update -D
> Can't locate LW
Just an update on this for reference.
Tried to install the missing IO::Socket::INET6 first, did not pass
tests either, then used the force flag on the DNS module, cpan -if
Net::DNS, restarted SA. URIBL rules starting to hit, jipe! Still
som eproblems running sa-update though. Seems
Hi all
Tried to install NET::DNS via CPAN to get my network tests going but
get the following error report at the end:
sudo cpan -i Net::DNS
Running make test
PERL_DL_NONLAZY=1 /usr/local/bin/perl "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib&#x
On Monday 18 September 2006 8:13 am, Sietse van Zanen wrote:
> Probably the writers of the module have decided to use strict references
> in their programming.
>
> You can do 1 of 2 things:
> 1. donwgrade back to 0.53.
> 2. edit the perl source for the new module and disable strict references.
> Th
'no strict 'refs'; under that. Or something down that road. Look at http://perldoc.perl.org/strict.html for more information.
-Sietse
From: ChrisSent: Mon 18-Sep-06 4:24To: users@spamassassin.apache.orgSubject: Problem after upgrade to Net::DNS 0.58
I'm running SA 3.1.5 an
On Sunday 17 September 2006 9:24 pm, Chris wrote:
> I'm running SA 3.1.5 and this evening upgraded to the above version of
> Net::DNS. Since then periodically I've been seeing this in my syslog:
As another question to this, I did an upgrade to the module instead a
removing the o
I'm running SA 3.1.5 and this evening upgraded to the above version of
Net::DNS. Since then periodically I've been seeing this in my syslog:
Sep 17 20:27:04 localhost spamd[1126]: Can't use string ("Net::DNS::RR::MX")
as a HASH ref while "strict refs" in use
On Thursday 27 July 2006 04:02, jdow wrote:
> So I use CPAN for SpamAssassin.
Every Distro supports Perl and CPAN.
So why not just stop releasing ANY distro specific RPMs
tars, emerges etc?
Make the CPAN distribution smart enough to work around
those perpetually broken cpan packages, or remov
From: "Radoslaw Zielinski" <[EMAIL PROTECTED]>
No, it doesn't trim out the rules. Unless the packager is mad.
I did NOT say the rules were left out. The TOOLS was left out, a
whole nice directory full of tools like the official SA version of
sa-stats.pl, and so forth. It normally appears as p
hey need a newer version of glibc.
Daryl,
Can you determine if 3.0.6 is safe to use with Net::DNS 0.49?
3.0.6 will exhibit the same occasional mix-ups as the rest of the 3.0
series, regardless of the version on Net::DNS installed.
Daryl
On Thu, 27 Jul 2006, Jeff Chan wrote:
> Fedora Core 4 doesn't seem to have 3.1.3 rpms that will work
> easily. In particular they need a newer version of glibc.
My virtual hosting site is running FC4. I compiled 3.1.3 from the
pristine source (after removing the 3.0.mumble RPM) and have had zero
jdow <[EMAIL PROTECTED]> [27-07-2006 14:02]:
> From: "Radoslaw Zielinski" <[EMAIL PROTECTED]>
[...]
>> Just get the *.spec file from the *.src.rpm, change Version: 3.0.x to
>> 3.1.4, put source in `rpmbuild -E %_sourcedir` and run rpmbuild -bb.
> Nah - I've learned not to use distro versions of Spa
From: "Radoslaw Zielinski" <[EMAIL PROTECTED]>
Jeff Chan <[EMAIL PROTECTED]> [27-07-2006 09:34]:
On Wednesday, July 26, 2006, 11:56:27 PM, Daryl O'Shea wrote:
On 7/27/2006 2:39 AM, jdow wrote:
[...]
I am running 3.0.6, essentially.
*shrug* not sure why you still insist on running 3.0.
Fedo
Jeff Chan <[EMAIL PROTECTED]> [27-07-2006 09:34]:
> On Wednesday, July 26, 2006, 11:56:27 PM, Daryl O'Shea wrote:
>> On 7/27/2006 2:39 AM, jdow wrote:
[...]
>>> I am running 3.0.6, essentially.
>> *shrug* not sure why you still insist on running 3.0.
> Fedora Core 4 doesn't seem to have 3.1.3 rpms
From: "Jeff Chan" <[EMAIL PROTECTED]>
On Wednesday, July 26, 2006, 11:56:27 PM, Daryl O'Shea wrote:
On 7/27/2006 2:39 AM, jdow wrote:
Both Jeff and I are perplexed over a trio of hits on newnanutilities.org
in a message referring to the Fedora update mirror they host.
Three mixed up hits o
From: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]>
On 7/27/2006 2:39 AM, jdow wrote:
Both Jeff and I are perplexed over a trio of hits on newnanutilities.org
in a message referring to the Fedora update mirror they host.
Three mixed up hits on separate messages? I could sort of see it
happening
rk
easily. In particular they need a newer version of glibc.
Daryl,
Can you determine if 3.0.6 is safe to use with Net::DNS 0.49?
Jeff C.
--
Jeff Chan
mailto:[EMAIL PROTECTED]
http://www.surbl.org/
On 7/27/2006 2:39 AM, jdow wrote:
Both Jeff and I are perplexed over a trio of hits on newnanutilities.org
in a message referring to the Fedora update mirror they host.
Three mixed up hits on separate messages? I could sort of see it
happening if the cache on all/most lookups for the message
From: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]>
On 7/27/2006 2:10 AM, Jeff Chan wrote:
Fedora Core 4 ships with SpamAssassin 3.0.3 and Net::DNS 0.49
installed by default.
Are both of these versions safe to use?
http://wiki.apache.org/spamassassin/Security
Do they a
On 7/27/2006 2:10 AM, Jeff Chan wrote:
Fedora Core 4 ships with SpamAssassin 3.0.3 and Net::DNS 0.49
installed by default.
Are both of these versions safe to use?
http://wiki.apache.org/spamassassin/Security
Do they avoid the
"DNS packets mixed up" bugs:
http://issues.
Fedora Core 4 ships with SpamAssassin 3.0.3 and Net::DNS 0.49
installed by default.
Are both of these versions safe to use? Do they avoid the
"DNS packets mixed up" bugs:
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3997
http://issues.apache.org/SpamAssassin/show_bug.c
/site_perl/5.8.8/Mail/SpamAssassin/Plugin/URIDNSBL.pm
line 718.
Jul 24 11:18:10 adlsrv4 spamd[97919]: Can't locate Net/DNS/RR/SOA.pm in
@INC (@INC contains: lib ../lib /usr/local/lib/perl5/site_perl/5.8.8
/usr/local/lib/perl5/5.8.8/BSDPAN
/usr/local/lib/perl5/site_perl/5.8.8/mach /usr/local/lib/
Did you updatedb before using locate?
Realistically, if you downloaded and installed the tarball, there should be a
DNS.pm somewhere. If nothing else, there should at least be one in the
tarball.
Perhaps try installing Net::DNS via cpan instead of using a tarball?
--
Regards
P
there should be
a DNS.pm somewhere. If nothing else, there should at least be one in the
tarball.
Perhaps try installing Net::DNS via cpan instead of using a tarball?
Did you check (locate) where your DNS.pm *is*?
Hi!
I did a locate and there is no DNS.pm file. As this is my first experience
with Spamassassin, i'm clueless about What should be done??
Regards
Padma
ERNET Helpdesk
wrote on Wed, 28 Dec 2005 14:25:41 +0530 (IST):
> I have downloaded and installed the Net-DNS-0.55.tar.gz file., any idea of
> what could be wrong.
Did you check (locate) where your DNS.pm *is*?
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services
I have spamassassin Version 3.0.4 running. The error I get in Debug mode
is
debug: failed to load Net::DNS::Resolver: Can't locate Net/DNS.pm in @INC
(@INC contains: /usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/mach /usr/local/lib/perl5/site_perl
/usr/loca
1 - 100 of 159 matches
Mail list logo
