Bug 1200167

Exact NVR is perl-Mail-DKIM-0.39-8.el7.noarch on RHEL 7.1

We will not rebase to 0.40 because it changes API. We can try to port to fix back to 0.39. However to prioritize your request properly, please contact Red Hat support.

Could you provide a pure Mail::DKIM reproducer? I could not reproduce it with /usr/share/doc/perl-Mail-DKIM-0.39/scripts/dkimverify.pl script on any of the e-mails from corpus directory in the Mail-DKIM sources. I could see some warning about undefined value, but no error about bad usage of IO::Socket::IP::_get_host_service().

(In reply to Petr Pisar from comment #3)
> Could you provide a pure Mail::DKIM reproducer? I could not reproduce it

It's easily reproducible with spamassassin. Basically every time it tries to look up a SPF record in DNS it fails with:

Mar  9 22:07:40 mail spamd[3263]: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
Mar  9 22:07:40 mail spamd[3263]: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
Mar  9 22:12:19 mail spamd[3263]: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
Mar  9 22:13:18 mail spamd[3263]: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
Mar  9 22:13:18 mail spamd[3263]: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
Mar  9 22:20:51 mail spamd[3263]: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
Mar  9 22:20:51 mail spamd[3263]: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
Mar  9 22:24:52 mail spamd[3263]: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
Mar  9 22:24:52 mail spamd[3263]: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.

I don't have a local reproducer, I'm not a perl coder and it was easier to take the Fedora version and rebuild it and put it in place. 

It's well documented in the upstream bug reports

https://rt.cpan.org/Public/Bug/Display.html?id=83170
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6872

The newer version works fine with spamassassin 3.4 which is the only package in RHEL that depends on it. Not tested amavisd-new but that's in EPEL

repoquery --whatrequires perl-Mail-DKIM
amavisd-new-0:2.9.1-5.el7.noarch
spamassassin-0:3.3.2-18.el7.x86_64
spamassassin-0:3.4.0-1.el7.x86_64

(In reply to Petr Pisar from comment #2)
> We will not rebase to 0.40 because it changes API. We can try to port to fix
> back to 0.39. However to prioritize your request properly, please contact
> Red Hat support.

Ultimately you as the maintainer need to make that decision, it's badly broken with spamassassin when using some DNS situations (google for the string from the logs above) which is a core part of it's functionality because both public domain keys and SPF records are stored in DNS.

(In reply to Peter Robinson from comment #4)
> (In reply to Petr Pisar from comment #3)
> > Could you provide a pure Mail::DKIM reproducer? I could not reproduce it
> 
> It's easily reproducible with spamassassin. Basically every time it tries to
> look up a SPF record in DNS it fails with:
> 
> Mar  9 22:07:40 mail spamd[3263]: spf: lookup failed: addr is not a string
> at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
[...]
> 
> I don't have a local reproducer, I'm not a perl coder and it was easier to
> take the Fedora version and rebuild it and put it in place. 
> 
I'm sorry. If you blame Mail::DKIM, you have to provide Mail::DKIM reproducer. Please contact Red Hat support to help you with it.

> I'm sorry. If you blame Mail::DKIM, you have to provide Mail::DKIM
> reproducer. Please contact Red Hat support to help you with it.

Err, no, please don't close it. All the details are in the upstream bug report with all the details on how to reproduce it.

I'm not a perl coder, it's not my job to slim down a reproducer, all the details of the problem are in the two upstream BZ. Please go and read them!

(In reply to Peter Robinson from comment #7)
> > I'm sorry. If you blame Mail::DKIM, you have to provide Mail::DKIM
> > reproducer. Please contact Red Hat support to help you with it.
> 
> Err, no, please don't close it. All the details are in the upstream bug
> report with all the details on how to reproduce it.
>
The upstream report does not provide any reproducer. I really recommend you to   contact Red Hat support team. Bugzilla is not a support channel for Red Hat Enterprise Linux customers.

Provided your only reproducer is "using spamd", I reassign the issue to spamassassin component. It's maintainer could now more how spamd uses Mail::DKIM.

Sorry, but even I can't reproduce your issue. Can you provide at least
1) versions you are using (spamassassin 3.3 or 3.4 -- there was rebase!)
2) special configuration?
when you can't provide any reproducer? I was going through the spamassassin code and how it is handling DKIM and I don't see anything strange.

Can you try to run example verifier from
https://metacpan.org/pod/Mail::DKIM::Verifier
on some of your messages on your system, if it will result in same error?
(Ex. $ cat signed.mail | perl verifier.pl )

Everything I tried ended up without any problem nor messages in journal. Both with plain DKIM and through spamc ( Ex. $ cat signed.mail | spamc -R ).

I was seeing the same thing until I disabled SPF plugin in init.pre.

But I would suspect this is rather an issue in perl-Mail-SPF. I don't understand why this would be a DKIM problem when SPF validation fails.

More useful information about the relation between spamassassin and perl-Mail-DKIM is here:
http://www.gossamer-threads.com/lists/spamassassin/users/189013#189013

According to that post, it is not a DKIM problem, but rather a bug with perl.  perl >= 5.18 fixes the issue.  Upgrading to a newer DKIM is a suggested fix because that seems to work around the issue, which might be easier to do than upgrade perl.

I am having the same issue.  SPF lookup in spamassassin seems to be broken after recent upgrade, I have clients complaining about receiving a lot of spam in their inbox.  This is a real problem for EL7 servers, which should be addressed quickly IMVHO.

My versions:
perl-5.16.3-285.el7.x86_64
perl-Mail-DKIM-0.39-8.el7.noarch
spamassassin-3.4.0-1.el7.x86_64

Meanwhile, on my system it seems to fixed after obtaining Fedora 19 package "perl-Mail-DKIM-0.40-1.fc19.noarch.rpm" and using yum to install it and its dependencies.  People desperate for a solution might want to try that.

same question. Do you have a reproducer? If none of us can reproduce it, we don't know what to fix, especially when the messages are from one component, bug in the second and reproducer is with the third.

I also have this bug on a fresh 7.1 machine and can confirm installing "perl-Mail-DKIM-0.40-1.fc19.noarch.rpm" via yum fixed the error's.

Jakub, perhaps it would be best if you gave us some suggestions on how we can create a reproducer.  I'm not a spamassassin developer and not the slighest versed in perl.  In the thread I linked to in comment #13 there is a reproducer for the perl bug, I'm not sure how to create a reproducer for the effects it has on spamassassin, other than to install spamassassin on an EL7 machine and look for errors in the maillog.

Jan, reproducer is list of all actions you need to do from fresh rhel7 installation to the error message in maillog. For sure there was missing some point that you should add some message to parse by spamd/spamc, to attach such message, or the use of specific dns resolver.

I have several rhel7 machines and reproducer "Install spamassassin and the logs will show up" doesn't work for me. I have this configuration for long, but no messages in maillog so there is probably something missing. I have all the same versions as you wrote.

Discussion linked in comment #13 gives little bit more clue about the problem (probably the best one for now), it looks like the important thing is using dns resolver 156.154.70.1, but I still have no luck with reproducing. Also it looks like problem with combination of perl version, Net::DNS version and Mail::DKIM version and some of these components will need to take some steps.

Only thing I managed to reproduce was error with pure perl code from [1].


Petr, what do you think about this now? As I browse through the code, I see there is compatibility fix for DNS in PublicKey.pl and Policy.pl in perl-Mail-DKIM-0.40, which should fix this issue.


@@ -105,9 +105,17 @@
 			}
 
 			my $strn;
-			foreach my $ans (@resp) {
-				next unless $ans->type eq "TXT";
-				$strn = join "", $ans->char_str_list;
+			foreach my $rr (@resp) {
+				next unless $rr->type eq "TXT";
+
+				# join with no intervening spaces, RFC 6376
+				if (Net::DNS->VERSION >= 0.69) {
+					# must call txtdata() in a list context
+					$strn = join "", $rr->txtdata;
+				} else {
+					# char_str_list method is 'historical'
+					$strn = join "", $rr->char_str_list;
+				}
 				last;
 			}


[1] http://www.gossamer-threads.com/lists/spamassassin/users/189005#189005

> logs will show up" doesn't work for me. I have this configuration for long,
> but no messages in maillog so there is probably something missing. I have
> all the same versions as you wrote.

What DNS servers are you using? I've not had time to dig further as I've been busy with $dayjob and updating to 0.40 fixed it for me, but it appears if you use opendns or google DNS (8.8.8.8 etc) that it works, and if you use something else (I use IPA/bind with upstream ISP forwarders) it seems to cause issues although I've not tested straight to google because I need internal IPA infra

I use CentOS 7.1 rather than RHEL, so take the following for whatever its worth.

I see these error messages in my logs every time a mail is processed by amavisd-new 2.9.1 which comes from the EPEL repository:

Apr 20 13:12:42 linode1 amavis[32133]: (32133-13) _WARN: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.
Apr 20 13:12:42 linode1 amavis[32133]: (32133-13) _WARN: spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.

As shown by Peter's repoquery, amavisd-new seems to be using perl-Mail-DKIM internally.

Like Peter, my DNS server is a local caching DNS server (bind) which recurses to my ISP. I have IPV6 enabled.

(In reply to Jakub Jelen from comment #18)
> Discussion linked in comment #13 gives little bit more clue about the
> problem (probably the best one for now), it looks like the important thing
> is using dns resolver 156.154.70.1, but I still have no luck with
> reproducing. Also it looks like problem with combination of perl version,
> Net::DNS version and Mail::DKIM version and some of these components will
> need to take some steps.
> 
> Only thing I managed to reproduce was error with pure perl code from [1].
>
> [1] http://www.gossamer-threads.com/lists/spamassassin/users/189005#189005

This looks like the real reason (besides changes in perl interpreter). Socket upstream applied two compatibility fixes <http://cpansearch.perl.org/src/PEVANS/Socket-2.018/Changes> two months ago both discussed in <https://rt.cpan.org/Public/Bug/Display.html?id=79557>:

2.018   2015/02/12 13:42:41
        [BUGFIXES]
         * Fix for "addr is not a string" test to use SvPOKp() before 5.18

2.017   2015/02/10 12:05:14
[...]
        [BUGFIXES]
         * Remember to SvGETMAGIC in getnameinfo() (RT79557)

I can try to isolate and apply them to RHEL-7's perl-Socket package. I can reproduce the "addr is not a string" error message from the Socket::getnameinfo(). However I cannot reproduce the Net::DNS or Mail::DKIM issue, so I cannot say if helps to the reporter.

> Petr, what do you think about this now? As I browse through the code, I see
> there is compatibility fix for DNS in PublicKey.pl and Policy.pl in
> perl-Mail-DKIM-0.40, which should fix this issue.
> 
> 
> @@ -105,9 +105,17 @@
>  			}
>  
>  			my $strn;
> -			foreach my $ans (@resp) {
> -				next unless $ans->type eq "TXT";
> -				$strn = join "", $ans->char_str_list;
> +			foreach my $rr (@resp) {
> +				next unless $rr->type eq "TXT";
> +
> +				# join with no intervening spaces, RFC 6376
> +				if (Net::DNS->VERSION >= 0.69) {
> +					# must call txtdata() in a list context
> +					$strn = join "", $rr->txtdata;
> +				} else {
> +					# char_str_list method is 'historical'
> +					$strn = join "", $rr->char_str_list;
> +				}
>  				last;
>  			}
> 
> 
This does not do anything important. It only prefers txtdata() over char_str_list() with recent Net::DNS. However the code in RHEL-7 Net::DNS only passes the call from char_str_list() to txtdata():

sub txtdata {
    my $self = shift;

    @{$self}{txtdata} = [map Net::DNS::Text->new($_), @_] if scalar @_;

    my $txtdata = $self->{txtdata} || [];

    return ( map $_->value, @$txtdata ) if wantarray;

    join ' ', map $_->value, @$txtdata if defined wantarray;
}


sub char_str_list {         ## historical
    return (&txtdata);
}

In other words, I don't believe that the quoted patch fixes the reported spamassassin issue.

(In reply to Petr Pisar from comment #21)
> This looks like the real reason (besides changes in perl interpreter).
> Socket upstream applied two compatibility fixes
> <http://cpansearch.perl.org/src/PEVANS/Socket-2.018/Changes> two months ago
> both discussed in <https://rt.cpan.org/Public/Bug/Display.html?id=79557>:
> 
> 2.018   2015/02/12 13:42:41
>         [BUGFIXES]
>          * Fix for "addr is not a string" test to use SvPOKp() before 5.18
> 
> 2.017   2015/02/10 12:05:14
> [...]
>         [BUGFIXES]
>          * Remember to SvGETMAGIC in getnameinfo() (RT79557)
> 
> I can try to isolate and apply them to RHEL-7's perl-Socket package. I can
> reproduce the "addr is not a string" error message from the
> Socket::getnameinfo(). However I cannot reproduce the Net::DNS or Mail::DKIM
> issue, so I cannot say if helps to the reporter.
> 
Here is a testing (i.e. not supported) build of RHEL-7's perl-Socket package with the deemed fix. Could reporter or other affected person test it whether it resolves the spamassassin issue?

(In reply to Petr Pisar from comment #22)
> Here is a testing (i.e. not supported) build of RHEL-7's perl-Socket package
> with the deemed fix. Could reporter or other affected person test it whether
> it resolves the spamassassin issue?

There <http://people.redhat.com/~ppisar/perl-Socket-2.010-4.el7/>.

(In reply to Petr Pisar from comment #22)
> Here is a testing (i.e. not supported) build of RHEL-7's perl-Socket package
> with the deemed fix. Could reporter or other affected person test it whether
> it resolves the spamassassin issue?

Petr, http://people.redhat.com/~ppisar/perl-Socket-2.010-4.el7/ fixes the problem I was seeing with "lookup failed: addr is not a string" reported from amavisd-new on CentOS 7.1.

With that fix, I also no longer see the errors from spamassassin.

Thank you for the confirmation.

Created attachment 1016689 [details]
Upstream fix ported to 2.010

How to test:

(1) Execute:
$ perl -Te 'use Socket; $s=$ENV{PATH}; $s=qq{2\0\0005\301\2\4\367\0\0\0\0\0\0\0\0}; Socket::getnameinfo($s,Socket::NI_NUMERICHOST|Socket::NI_NUMERICSERV)'
(2) Check exit code:
  Before: The command fails, exit code is non-zero, "addr is not a string at -e line 1." is printed on error output.
  After: The command passes, exit code is zero, no error is printed.

Please note that the test fails only with Perl 5.16.

yes, I can confirm that
perl-Socket-2.010-4.el7_1.x86_64.rpm solves this issue.

So:
wget http://people.redhat.com/ppisar/perl-Socket-2.010-4.el7/perl-Socket-2.010-4.el7_1.x86_64.rpm

AND

yum update perl-Socket-2.010-4.el7_1.x86_64.rpm

automatically replaces the old perl-Socket-2.010-3.el7.x86_64

bye bye ;-)

Hello,

any news on the progress of this bug please?

How to test:
1) Install perl, perl(Socket) and perl(Devel::Peek)
2) Run command

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)' 

Output should not contains any error like "addr is not a string at"

I can confirm that

http://people.redhat.com/ppisar/perl-Socket-2.010-4.el7/perl-Socket-2.010-4.el7_1.x86_64.rpm

Solved the problem on my Centos 7.2.1511 installation with error:

spf: lookup failed: addr is not a string at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 662.

Since its taking years to fix this problem, I "fixed" it by running SPF checks under Postfix instead of SpamAssassin. Postfix is not a perl application, thus not encumbered by this bug.

I can also confirm that http://people.redhat.com/ppisar/perl-Socket-2.010-4.el7/perl-Socket-2.010-4.el7_1.x86_64.rpm fixes the problem on 7.2.

Can we get this pushed along?

It looks good to me.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2196.html