Jump to content

ipv6


halloween

Recommended Posts

...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.

Link to comment
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)?"
Link to comment
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).

Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

  • 1 month later...
  • 2 months later...

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.

Link to comment
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.

Link to comment
Share on other sites

  • 5 months later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...