Sign in to follow this  
Followers 0
halloween

ipv6

38 posts in this topic

...IIUC, that won't cause "sidelining" of SpamCop. The only symptom would be that fewer IP addresses are blacklisted than would otherwise happen but I suspect that SpamCop staff are not tracking anything that would identify this.

I've managed to completely automate the process and have solved the ipv6 problem, simply by unwrapping the headers, and replace any ipv6 "Received:" fields with "X-Received-ipv6" using the Perl's Regexp::IPv6

package:

use Regexp::IPv6 qw($IPv6_re);

# replace received fields if ipv6 for spamcop
sub filteripv6($) {
  my $msg=shift;

  $msg=~s/\r\n/\n/gs;
  $msg=~s/\r/\n/gs;
  my ($header,$body) = $msg=~/^(.*?)\n\n(.*)$/s;
  $header=~s/\n[ \t]+/\t/gs; # unwrap
  my [at]aHeader=split(/\n/, $header);
  my $NewHeader="";
  foreach my $line ([at]aHeader) {
	if ($line =~ /^Received:/i) {
	  if ($line =~ /$IPv6_re/) {
		$line =~ s/^Received:/X-Received-ipv6:/i;
	  }
	}
	$line=~s/\t/\n\t/sg; # rewrap
	$NewHeader.=$line. "\n";
  }
  $msg=$NewHeader."\n".$body;
  return($msg);
}

With a bit of work in php it could be added to squirrelmail's spamcop plugin.

I can't imagine that it would be too difficult for spamcop to use this to parse and skip ipv6s until the new code is ready.

Share this post


Link to post
Share on other sites
I've managed to completely automate the process and have solved the ipv6 problem, simply by unwrapping the headers, and replace any ipv6 "Received:" fields with "X-Received-ipv6" using the Perl's Regexp::IPv6

package:

<snip>

...Warning! Please see SCWiki article "Material changes to spam" and SpamCop FAQ (links to which can be found near the top left of each SpamCop Forum page) article "What if I break the rule(s)?"

Share this post


Link to post
Share on other sites

...IIUC, that won't cause "sidelining" of SpamCop. The only symptom would be that fewer IP addresses are blacklisted than would otherwise happen but I suspect that SpamCop staff are not tracking anything that would identify this.

Imagine if every single spam reported to SpamCop for a week contained a forged IPv6 header. Every single email reported by every single user is unable to be processed. While I doubt that SpamCop has monitoring in place to notice a slight drop in the number of reports (especially since spam numbers fluctuate so much to begin with), I would certainly hope they'd noticed if it dropped from whatever they currently see down to 0. I would also assume that users would bring it up if every single email they tried to report for a full week wasn't able to be processed.

I'm not saying that this will (or even that I want it to) happen. However, it seems like a large loophole that's being ignored because it's not being exploited currently, and it seems like it would be fairly easy to fix. As several of us have said, we understand that it isn't necessarily easy to add IPv6 header processing, but it shouldn't be too hard to modify the existing IPv6 detection mechanism so that it only applies to valid headers. Until true IPv6 processing is added, there are always going to be a few spams that it can't handle, but that seems like a much better solution than simply dropping any email that has an IPv6 address anywhere in it (forged or not).

Share this post


Link to post
Share on other sites

Received: from METEXC1.mettel.net ([fe80::6d95:2be4:ffc7:d20a]) by MetEXC2.mettel.net ([fe80::b5d7:e10e:5c22:1da8%16]) with mapi id 14.01.0355.002; Fri, 30 Mar 2012 07:24:12 -0400

Unable to process header. IPv6 addresses are not supported.

No source IP address found, cannot proceed.

I too would like to see support for ipv6. In the mean time I will open tickets with the mail provider to null route them.

Share this post


Link to post
Share on other sites

Hi, halloween,

...Uh-oh, IPv6 is reported to be fixed (Scheduled Service Outage)! Please post a Tracking URL.

Yes, I had a report with IPv6 that worked - good to see. This one worked:

Received: from oproxy11-pub.bluehost.com (unknown [2605:dc00:100:2::a3])

by www.xxx.yyy.zzz with SMTP;

This one did not:

Received: from oproxy11-pub.bluehost.com (unknown [iPv6:2605:dc00:100:2::a3])

by www.xxx.yyy.zzz with SMTP;

This is more a problem with the mailer adding the IPv6: bogus part I believe, but it's worth mentioning in case others hit this issue. I don't know what mailers add that tag, but it may be worth adding something to be defensive in the spamcop processor - perhaps with warnings in the report summary.

Share this post


Link to post
Share on other sites

...I suppose it could be because of the "IPv6" prefix in the string "[iPv6:2605:dc00:100:2::a3]," as you suggest, but I don't know exactly what the SpamCop parser is expecting and why. I would suggest that if you don't get a satisfactory answer from anyone else here and no one with a "SpamCop" tag, such as Don D'Minion ("SpamCop Admin"), replies, you drop a note to the SpamCop Deputies at deputies[at]admin.spamcop.net.

Share this post


Link to post
Share on other sites

I'm getting few spam messages that are marked as "cannot proceed because of IPv6" every day.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0