You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Thomas Preißler <th...@preissler.me> on 2014/10/26 23:04:05 UTC
spf: lookup failed: addr is not a string
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 find a mail.eml and the output of spamassassin -D which
shows the warning.
Any ideas how to solve this issue?
Thanks!
Thomas
Re: spf: lookup failed: addr is not a string
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 10/27/2014 12:58 PM, Thomas Preißler wrote:
> Hey KAM,
>
>> On Oct 27, 2014, at 5:34 PM, Kevin A. McGrail <km...@pccc.com> 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 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.8.8.8
> there is no error message from spamassassin.
I don't mean something that caches forwarded resolution calls. I mean a
real, local nameserver that needs the root hints to do it's own
recursion, etc.
Regards,
KAM
Re: spf: lookup failed: addr is not a string
Posted by Reindl Harald <h....@thelounge.net>.
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 as a local resolver. But when unbound caches 8.8.8.8
>> there is no error message from spamassassin.
>
> 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) ?
>
> Try capturing a query & response with 156.154.70.1 on the wire
> (e.g.: tcpdump -s 0 -w 0.log 'host 156.154.70.1 or icmp' )
> while running your mail sample through spamassassin, and see if
> there is anything funny there.
if you have some Cisco crap:
no ip nat service alg udp dns
no ip nat service alg tcp dns
frankly i wasted a lot of hours of my lifetime because our ISP ships
that enabled which leads to all sort of troubles like hanging
zone-transfers or even mangle them and put a zero TTL in fornt of any
CNAME block
Re: spf: lookup failed: addr is not a string
Posted by Mark Martinec <Ma...@ijs.si>.
> 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 noteworthy compatibility differences
> between 5.14 / 5.16 and 5.18 / 5.20. I don't think anything
> needed to be changed either in SpamAssassin or in Amavis
> to make it run under 5.18 or 5.20.
Seems that the change in Spampd between 2.30 and 2.42
was needed because of a change in a module Getopt::Long :
Changes in version 2.39
* Retain taintedness of command line option values.
and is unrelated to a version of perl.
Mark
Re: spf: lookup failed: addr is not a string
Posted by Mark Martinec <Ma...@ijs.si>.
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 unrelated ?
Don't know about Spampd, it's probably unrelated.
The upgrade of Mail::DKIM in this context was mentioned because
it avoids an issue in an unrelated piece of code, as SpamAssassin
can use a feature offered by a newer Mail::DKIM, which happened to
provide a workaround for the getnameinfo() problem. The Mail::DKIM
itself does not have a problem with running under any of the last
five or so major versions of perl.
I'm not aware of any noteworthy compatibility differences
between 5.14 / 5.16 and 5.18 / 5.20. I don't think anything
needed to be changed either in SpamAssassin or in Amavis
to make it run under 5.18 or 5.20.
The main benefit of using a newer version of perl is avoiding
several old bugs in perl core or modules. Some of these bugs
required workarounds in our code (like several taint-related bugs
in Encode, some utf8-related bugs in regexp evaluation).
There are a couple of stricter warnings issued with each newer
version of perl, but these just reveal some hidden bugs in our
application code and needed to be fixed anyway, perl made them
easier to find. Just recently I needed to fix/avoid two such
warnings under perl 5.21.5 in SpamAssassin (trunk), as well as
in Amavisd (2.10.1).
Other benefits are: updated some essential core modules
(like Encode, Digest::SHA, Socket, and IO::Socket::IP), as well
as some speedups and improved Unicode support.
Mark
Re: spf: lookup failed: addr is not a string
Posted by Benny Pedersen <me...@junc.eu>.
On October 29, 2014 8:52:40 PM Mark Martinec <Ma...@ijs.si> 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 unrelated ?
Re: spf: lookup failed: addr is not a string
Posted by Mark Martinec <Ma...@ijs.si>.
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::INET,
>> while the rest of the SpamAssassin's DNS resolving goes through
>> IO::Socket::IP. For some reason a TCP DNS request by Net::DNS
>> affects the socket used by IO::Socket::IP, making a variable
>> holding a string also get a numerical component, and moreover
>> it becomes tainted. In the end the getnameinfo() falls into
>> the snag. Weird...
>
> The only way to fix this issue is to update Mail::DKIM? I’m gonna ask
> the maintainer to upload an update to wheezy-backports.
Can't hurt to have an up-to-date version of Mail::DKIM.
There may be other workarounds, I'm still looking into the matter.
Here is a short indicator of the problem:
perl -Te 'use Socket; use Devel::Peek; $s=$ENV{PATH};
$s=0; $s="\2\0\0005\301\2\4\367\0\0\0\0\0\0\0\0";
Devel::Peek::Dump($s); Socket::getnameinfo($s,0)'
It stumbles across 'addr is not a string' in getnameinfo
with perl 5.14 and 5.16.
The problem is solved with perl 5.18, 5.20, 5.21.5,
which deal with pPOK vs. POK flags somewhat differently.
Mark
Re: spf: lookup failed: addr is not a string
Posted by Thomas Preißler <th...@preissler.me>.
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,
> while the rest of the SpamAssassin's DNS resolving goes through
> IO::Socket::IP. For some reason a TCP DNS request by Net::DNS
> affects the socket used by IO::Socket::IP, making a variable
> holding a string also get a numerical component, and moreover
> it becomes tainted. In the end the getnameinfo() falls into
> the snag. Weird...
The only way to fix this issue is to update Mail::DKIM? I’m gonna ask the maintainer to upload an update to wheezy-backports.
Thanks!
Thomas
Re: spf: lookup failed: addr is not a string
Posted by Mark Martinec <Ma...@ijs.si>.
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 only nameserver in /etc/resolv.conf
> - run spamassassin -D < mail.eml
>
> But removing libmail-dkim-perl is not really a solution. This package
> provides the Mail::DKIM module which is required to check the DKIM
> signature.
Thanks, I can now reproduce this.
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,
while the rest of the SpamAssassin's DNS resolving goes through
IO::Socket::IP. For some reason a TCP DNS request by Net::DNS
affects the socket used by IO::Socket::IP, making a variable
holding a string also get a numerical component, and moreover
it becomes tainted. In the end the getnameinfo() falls into
the snag. Weird...
Mark
Re: spf: lookup failed: addr is not a string
Posted by Thomas Preißler <th...@preissler.me>.
Hey!
> On Oct 28, 2014, at 10:51 AM, Thomas Preißler <th...@preissler.me> 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, the network is not the culprit. I tried to apply my chef recipes to a virtual machine on my desktop computer (different network) and get the same message from spamassassin. But when I try to install debian wheezy, spamassassin and unbound manually I’m not able to reproduce this issue anymore. There must be any package or configuration option in my chef recipes that causes spamassassin to fail the DNS lookup. I’ll further investigate this issue tomorrow.
>
It looks like the problem appears only with the package libmail-dkim-perl and some nameservers.
If I uninstall this package or use 8.8.8.8 as the DNS server I don’t get the message “spf: lookup failure” anymore.
The response of the two mail servers seems to be pretty much the same. There is just a very small difference if you ask for the dnssec signature: "dig @ip SPF mail.sys4.de +dnssec"
156.154.70.1 shows "EDNS: version: 0, flags: do; udp: 4096"
8.8.8.8 shows “EDNS: version: 0, flags: do; udp: 512"
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 only nameserver in /etc/resolv.conf
- run spamassassin -D < mail.eml
But removing libmail-dkim-perl is not really a solution. This package provides the Mail::DKIM module which is required to check the DKIM signature.
Thanks!
Thomas
Sent with Unibox
Re: spf: lookup failed: addr is not a string
Posted by Thomas Preißler <th...@preissler.me>.
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 my desktop computer (different network) and get the same message from spamassassin. But when I try to install debian wheezy, spamassassin and unbound manually I’m not able to reproduce this issue anymore. There must be any package or configuration option in my chef recipes that causes spamassassin to fail the DNS lookup. I’ll further investigate this issue tomorrow.
Thanks!
Thomas
Re: spf: lookup failed: addr is not a string
Posted by Mark Martinec <Ma...@ijs.si>.
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.8.8.8
> there is no error message from spamassassin.
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) ?
Try capturing a query & response with 156.154.70.1 on the wire
(e.g.: tcpdump -s 0 -w 0.log 'host 156.154.70.1 or icmp' )
while running your mail sample through spamassassin, and see if
there is anything funny there.
Mark
Re: spf: lookup failed: addr is not a string
Posted by Thomas Preißler <th...@preissler.me>.
Hey KAM,
> On Oct 27, 2014, at 5:34 PM, Kevin A. McGrail <km...@pccc.com> 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 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.8.8.8 there is no error message from spamassassin.
Thanks!
Thomas
Re: spf: lookup failed: addr is not a string
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 failure as well.
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.
Regards,
KAM
Re: spf: lookup failed: addr is not a string
Posted by Thomas Preißler <th...@preissler.me>.
Hey Kam,
thanks for getting back!
I nailed it down a bit.
If I use Google DNS (8.8.8.8) I don't get the message, whereas when
using other DNS servers (e.g. 156.154.70.1) spamassassin reports the spf
lookup failure. But using 'dig @ip SPF mail.sys4.de' shows pretty much
the same result.
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
failure as well.
Are you able to reproduce this issue?
Thanks!
Thomas
On 2014-10-27 15:30, Kevin A. McGrail wrote:
> 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 mail.eml and the output of spamassassin -D
>> which shows the warning.
>>
>> Any ideas how to solve this issue? Thomas, are you seeing the issue
>> still because I could not replicate:
>
> Oct 27 10:28:38.031 [8662] dbg: spf: checking to see if the message
> has a Received-SPF header that we can use
> Oct 27 10:28:38.177 [8662] dbg: spf: using Mail::SPF for SPF checks
> Oct 27 10:28:38.177 [8662] dbg: spf: checking HELO (helo=mail.sys4.de,
> ip=194.126.158.139)
> Oct 27 10:28:38.184 [8662] dbg: dns: providing a callback for id:
> 19578/IN/SPF/mail.sys4.de
> Oct 27 10:28:38.304 [8662] dbg: spf: query for
> /194.126.158.139/mail.sys4.de: result: none, comment: , text: No
> applicable sender policy available
> Oct 27 10:28:38.325 [8662] dbg: spf: already checked for Received-SPF
> headers, proceeding with DNS based checks
> Oct 27 10:28:38.326 [8662] dbg: spf: relayed through one or more
> trusted relays, cannot use header-based Envelope-From, skipping
> Oct 27 10:28:38.355 [8662] dbg: spf: def_spf_whitelist_from: already
> checked spf and didn't get pass, skipping whitelist check
> Oct 27 10:28:38.363 [8662] dbg: spf: whitelist_from_spf: already
> checked spf and didn't get pass, skipping whitelist check
>
> My thoughts are perhaps they fixed their SPF record or you had a
> temporary DNS issue?
>
> regards,
> KAM
Re: spf: lookup failed: addr is not a string
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 mail.eml and the output of spamassassin -D
> which shows the warning.
>
> Any ideas how to solve this issue?
Thomas, are you seeing the issue still because I could not replicate:
Oct 27 10:28:38.031 [8662] dbg: spf: checking to see if the message has
a Received-SPF header that we can use
Oct 27 10:28:38.177 [8662] dbg: spf: using Mail::SPF for SPF checks
Oct 27 10:28:38.177 [8662] dbg: spf: checking HELO (helo=mail.sys4.de,
ip=194.126.158.139)
Oct 27 10:28:38.184 [8662] dbg: dns: providing a callback for id:
19578/IN/SPF/mail.sys4.de
Oct 27 10:28:38.304 [8662] dbg: spf: query for
/194.126.158.139/mail.sys4.de: result: none, comment: , text: No
applicable sender policy available
Oct 27 10:28:38.325 [8662] dbg: spf: already checked for Received-SPF
headers, proceeding with DNS based checks
Oct 27 10:28:38.326 [8662] dbg: spf: relayed through one or more trusted
relays, cannot use header-based Envelope-From, skipping
Oct 27 10:28:38.355 [8662] dbg: spf: def_spf_whitelist_from: already
checked spf and didn't get pass, skipping whitelist check
Oct 27 10:28:38.363 [8662] dbg: spf: whitelist_from_spf: already checked
spf and didn't get pass, skipping whitelist check
My thoughts are perhaps they fixed their SPF record or you had a
temporary DNS issue?
regards,
KAM
Re: spf: lookup failed: addr is not a string
Posted by Alessio Cecchi <al...@skye.it>.
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 find a mail.eml and the output of spamassassin -D
> which shows the warning.
>
> Any ideas how to solve this issue?
>
> Thanks!
> Thomas
Hi,
I solved this issue with "minimal-responses yes;" in bind9 options:
options {
[...]
minimal-responses yes; # avoid spfquery BUGs