Bug 6573 - [review] Report for IPv6 IP hitting DNS BL/WL is broken
Summary: [review] Report for IPv6 IP hitting DNS BL/WL is broken
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P2 normal
Target Milestone: 3.4.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard: ready to commit for 3.4
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-15 12:44 UTC by Darxus
Modified: 2011-05-05 18:16 UTC (History)
3 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Darxus 2011-04-15 12:44:17 UTC
For IPv6 IP 2001:470:f329:1::1 in zone iprep.chaosreigns.com, it's reporting:

-0.1 RCVD_IN_IPREPDNS_100   RBL: Sender listed at
                            http://www.chaosreigns.com/iprep/, 100% ham
[0.0.0.1 listed in 0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.9.2.3.f.0.7.4.0.1.0.0.2.iprep.chaosreigns.com]

When it should be reporting:


-0.1 RCVD_IN_IPREPDNS_100   RBL: Sender listed at
                            http://www.chaosreigns.com/iprep/, 100% ham
                            [2001:470:f329:1::1 listed in iprep.chaosreigns.com]


The IP was 2001:470:f329:1::1.  In long form, that's 2001:0470:f329:0001:0000:0000:0000:0001.  So the PTR record is all the integers, in reverse order, with dots in between all of them:  1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.9.2.3.f.0.7.4.0.1.0.0.2.ip6.arpa.  Which makes the DNS BL/WL record in zone iprep.chaosreigns.com: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.9.2.3.f.0.7.4.0.1.0.0.2.iprep.chaosreigns.com.

So it looks like the report is just splitting that at the 4th dot, and considering the first part the IP (reversed), and the second part the zone, which is reasonable enough for IPv4, but wrong for IPv6.
Comment 1 Mark Martinec 2011-05-04 16:15:32 UTC
Thanks! Now fixed I suppose:

trunk:
  $ svn ci -m 'Bug 6573: Report for IPv6 IP hitting DNS BL/WL is broken'
  Sending lib/Mail/SpamAssassin/Dns.pm
Committed revision 1099506.
Comment 2 Kevin A. McGrail 2011-05-05 11:56:02 UTC
(In reply to comment #1)
> Thanks! Now fixed I suppose:
> 
> trunk:
>   $ svn ci -m 'Bug 6573: Report for IPv6 IP hitting DNS BL/WL is broken'
>   Sending lib/Mail/SpamAssassin/Dns.pm
> Committed revision 1099506.

We are talking about this patch, yes?  If so, I don't use IPv6 but I really liked the empty if comment change.

I don't use IPv6 but I was looking for a type eq 'AA' so if this works, I see the logic as good but it confuses me a bit.

Index: Dns.pm
===================================================================
--- Dns.pm      (revision 1040623)
+++ Dns.pm      (working copy)
@@ -182,15 +182,26 @@
   my ($self, $rule, $question, $answer) = @_;
 
   my $log = "";
-  if (substr($rule, 0, 2) ne "__") {
-    if ($answer->type eq 'TXT') {
-      $log = $answer->rdatastr;
-      $log =~ s/^"(.*)"$/$1/;
-      $log =~ s/(?<![<([])(https?:\/\/\S+)/<$1>/gi;
+  if (substr($rule, 0, 2) eq "__") {
+    # don't bother with meta rules
+  } elsif ($answer->type eq 'TXT') {
+    local $1;
+    $log = $answer->rdatastr;
+    $log =~ s/^"(.*)"$/$1/;
+    $log =~ s/(?<![<([])(https?:\/\/\S+)/<$1>/gi;
+  } else {  # assuming $answer->type eq 'A'
+    local($1,$2,$3,$4,$5);
+    if ($question->string =~ m/^((?:[0-9a-fA-F]\.){32})(\S+\w)/) {
+      $log = ' listed in ' . lc($2);
+      my $ipv6addr = join('', reverse split(/\./, lc $1));
+      $ipv6addr =~ s/\G(....)/$1:/g;  chop $ipv6addr;
+      $ipv6addr =~ s/:0{1,3}/:/g;
+      $log = $ipv6addr . $log;
+    } elsif ($question->string =~ m/^(\d+)\.(\d+)\.(\d+)\.(\d+)\.(\S+\w)/) {
+      $log = "$4.$3.$2.$1 listed in " . lc($5);
+    } else {
+      $log = 'listed in ' . $question->string;
     }
-    elsif ($question->string =~ m/^(\d+)\.(\d+)\.(\d+)\.(\d+)\.(\S+\w)/) {
-      $log = "$4.$3.$2.$1 listed in ".lc($5);
-    }
   }
 
   # TODO: this may result in some log messages appearing under the
@@ -281,9 +292,9 @@
   while (my ($subtest, $rule) = each %{ $self->{dnspost}->{$set} }) {
     next if $self->{tests_already_hit}->{$rule};
 
-    # exact substr (usually IP address)
-    if ($subtest eq $rdatastr) {
-      $self->dnsbl_hit($rule, $question, $answer);
+    if ($subtest =~ /^\d+\.\d+\.\d+\.\d+$/) {
+      # test for exact equality, not a regexp (usually IP address)
+      $self->dnsbl_hit($rule, $question, $answer)  if $subtest eq $rdatastr;
     }
     # senderbase
     elsif ($subtest =~ s/^sb://) {
Comment 3 Mark Martinec 2011-05-05 12:50:30 UTC
> We are talking about this patch, yes?  If so, I don't use IPv6 but I really
> liked the empty if comment change. 
> I don't use IPv6 but I was looking for a type eq 'AA' so if this works, I see
> the logic as good but it confuses me a bit.

Sorry, I don't think I understand what you are trying to say.

> --- Dns.pm      (revision 1040623)
> +++ Dns.pm      (working copy)
> @@ -182,15 +182,26 @@
[...]

Yes, this patch chunk is what we are taking about, a change
in sub dnsbl_hit. As shown by: svn diff -c1099506

> @@ -281,9 +292,9 @@
[...]

Not this one. This chunk is from Bug 6565, unrelated.
Comment 4 Kevin A. McGrail 2011-05-05 12:54:09 UTC
(In reply to comment #3)
> > We are talking about this patch, yes?  If so, I don't use IPv6 but I really
> > liked the empty if comment change. 
> > I don't use IPv6 but I was looking for a type eq 'AA' so if this works, I see
> > the logic as good but it confuses me a bit.
> 
> Sorry, I don't think I understand what you are trying to say.

That's because I MEANT to write 'AAAA'.  If we get an IPv6 answer, won't it have a type of AAAA and not A?

So maybe an elseif $answer->type eq 'AAAA' is needed rather than assuming A?

> Yes, this patch chunk is what we are taking about, a change
> in sub dnsbl_hit. As shown by: svn diff -c1099506

Thanks.  I was using svn diff Dns.pm -r 1040623
Comment 5 Mark Martinec 2011-05-05 13:14:24 UTC
> If we get an IPv6 answer, won't it
> have a type of AAAA and not A?
> So maybe an elseif $answer->type eq 'AAAA' is needed rather than assuming A?

Not in case of querying DNS WBL servers. The query is for an A record
(expecting an answer like 127.0.0.x), even if a domain in a question
section is composed similar to a PTR query for an IPv6 address.

We are currently never issuing a DNS query of an AAAA type.
I just left the assumption as it was, not strengthening it
(for fear of potentially breaking some unanticipated case).
Comment 6 Kevin A. McGrail 2011-05-05 13:27:12 UTC
OK, so this code really does nothing more than formatting changes.  I'm +1 though I can't test.  Even if it's wrong, it's only cleaning up textual output and the logic looks sound.
Comment 7 Darxus 2011-05-05 14:57:42 UTC
Works for me:

 pts rule name              description
---- ---------------------- --------------------------------------------------
-0.1 RCVD_IN_IPREPDNS_100   RBL: Sender listed at
                            http://www.chaosreigns.com/iprep/, 100% ham
                            [2001:470:1f0f:201:0:0:0:2 listed in]
                            [iprep.chaosreigns.com]
Comment 8 Henrik Krohns 2011-05-05 18:11:38 UTC
ok looked fine for me.. +1 3.4
Comment 9 Mark Martinec 2011-05-05 18:16:40 UTC
Closing. Already in trunk.