Am 26.12.2014 um 17:58 schrieb Mark Martinec:
http://www.gossamer-threads.com/lists/spamassassin/users/188895
Has anyone made any progress on this? Anyone found a workaround?
Yes, it's the same issue. The bug is in perl, fixed in 5.18 or later.
A minimal test program triggering the bug was p
Michael Grant wrote:
I'm getting this message in my mail.log:
spamd: spf: lookup failed: addr is not a string at
/usr/share/perl5/IO/Socket/IP.pm line 646.
I'm running debian stable with Spamassassin from backports:
SpamAssassin Server version 3.4.0
running on Perl 5.14.2
a
Am 26.12.2014 um 16:05 schrieb Michael Grant:
I'm getting this message in my mail.log:
spamd: spf: lookup failed: addr is not a string at
/usr/share/perl5/IO/Socket/IP.pm line 646.
I'm running debian stable with Spamassassin from backports:
SpamAssassin Server version 3.4.0
I'm getting this message in my mail.log:
spamd: spf: lookup failed: addr is not a string at
/usr/share/perl5/IO/Socket/IP.pm line 646.
I'm running debian stable with Spamassassin from backports:
SpamAssassin Server version 3.4.0
running on Perl 5.14.2
and libmail-dkim-perl version
Benny Pedersen wrote:
Spampd 2.30 does not work with perl 5.18, spampd 2.42 does, seem lot
is changed in perl, so is it not just mail::dkim that needs updates
for perl 5.18 ?
Or is it unrelated ?
me wrote:
Don't know about Spampd, it's probably unrelated.
[...]
I'm not aware of any noteworth
Il 26/10/2014 23:04, Thomas Preißler ha scritto:
Hey!
I use SpamAssassin version 3.4.0 from wheezy-backports. Unfortunately,
I get the following line sometimes in mail.log:
warn: spf: lookup failed: addr is not a string at
/usr/share/perl5/IO/Socket/IP.pm line 646.
Attached you'll f
Benny Pedersen wrote:
The problem is solved with perl 5.18, 5.20, 5.21.5,
which deal with pPOK vs. POK flags somewhat differently.
Spampd 2.30 does not work with perl 5.18, spampd 2.42 does, seem lot
is changed in perl, so is it not just mail::dkim that needs updates
for perl 5.18 ?
Or is it u
On October 29, 2014 8:52:40 PM Mark Martinec wrote:
The problem is solved with perl 5.18, 5.20, 5.21.5,
which deal with pPOK vs. POK flags somewhat differently.
Spampd 2.30 does not work with perl 5.18, spampd 2.42 does, seem lot is
changed in perl, so is it not just mail::dkim that needs up
Thomas Preißler wrote:
Hey Mark,
thanks for your explanation!
I'm beginning to understand what is going on here.
Because you have a older version of Mail::DKIM, spamassassin is
unable to provide it with its own resolver, so Mail::DKIM does
it by directly calling Net::DNS, which uses IO::Socket:
Hey Mark,
thanks for your explanation!
> I'm beginning to understand what is going on here.
> Because you have a older version of Mail::DKIM, spamassassin is
> unable to provide it with its own resolver, so Mail::DKIM does
> it by directly calling Net::DNS, which uses IO::Socket::INET,
> whil
On 2014-10-28 13:25, Thomas Preißler wrote:
Finally, I’m able to reproduce this issue on a plain debian wheezy system:
- install debian wheezy
- enable backports and run apt-get update
- apt-get -t wheezy-backports install spamassassin
- apt-get install libmail-dkim-perl
- set 156.154.70.1 as the
Hey!
> On Oct 28, 2014, at 10:51 AM, Thomas Preißler wrote:
>
>
> Hey Mark,
>
>
>> Do you have a firewall in place that tries to do a deep packet
>> inspection
>> on DNS UDP packets but does not understand EDNS0 (the OPT RR) ?
>>
>>
>
>
> thanks for the suggestion!
> Unfortunately, th
Hey Mark,
> Do you have a firewall in place that tries to do a deep packet
> inspection
> on DNS UDP packets but does not understand EDNS0 (the OPT RR) ?
>
>
thanks for the suggestion!
Unfortunately, the network is not the culprit. I tried to apply my chef recipes
to a virtual machine on
Am 27.10.2014 um 20:00 schrieb Mark Martinec:
Thomas Preißler wrote:
Already tried that. When using unbound as a local caching nameserver
and 156.154.70.1 as the resolver, spamassassin produces the same error
message. The same happens when unbound accesses the root nameservers
directly and acts
Thomas Preißler wrote:
Already tried that. When using unbound as a local caching nameserver
and 156.154.70.1 as the resolver, spamassassin produces the same error
message. The same happens when unbound accesses the root nameservers
directly and acts as a local resolver. But when unbound caches 8.
On 10/27/2014 12:58 PM, Thomas Preißler wrote:
Hey KAM,
On Oct 27, 2014, at 5:34 PM, Kevin A. McGrail wrote:
Using SA really requires a local caching naming server. This fixes more
than a handful of problems. Switch to that and see if your issue is
resolved.
Already tried that. When using u
Hey KAM,
> On Oct 27, 2014, at 5:34 PM, Kevin A. McGrail wrote:>
> > Using SA really requires a local caching naming server. This fixes more
> > than a handful of problems. Switch to that and see if your issue is
> resolved.
>
Already tried that. When using unbound as a local cachin
On 10/27/2014 12:22 PM, Thomas Preißler wrote:
I've attached two files which contain the output of spamassassin -D.
- ok.log shows the output when using 8.8.8.8
- failed.log shows the output when using 156.154.70.1
I tried unbound as a local DNS resolver, but it produces the spf
lookup failur
On 10/26/2014 6:04 PM, Thomas Preißler wrote:
I use SpamAssassin version 3.4.0 from wheezy-backports. Unfortunately,
I get the following line sometimes in mail.log:
warn: spf: lookup failed: addr is not a string at
/usr/share/perl5/IO/Socket/IP.pm line 646.
Attached you'll find a mai
19 matches
Mail list logo
