Sign in to follow this  
Followers 0
SpamCopAdmin

IPv6 Routing Support

84 posts in this topic

SpamCop plans to implement support for IPv6 headers later this year.

- Don D'Minion - SpamCop Admin -

- service[at]admin.spamcop.net -

.

[pinned]

Edited by Farelf

Share this post


Link to post
Share on other sites

That should already be don by now. I can’t report spam any more without replacing the IPv6 address in the header. My provider is routing the e-mail internally all over IPv6, since some time early this year. So all mail has a IPv6 address in the header.

If spamcop would at least give an error message indicating that IPv6 is not supportet yet. Instead only the Message “No source IP address found, cannot proceed.†is shown without any indication of IPv6.

Share this post


Link to post
Share on other sites
That should already be don by now.

One would like to think so, and yet ...... ton loads of hardware still in use around the world that's not capable yet. (and let's try not to think about all those home/personal routers that won't make the upgrade boat.)

Please see World IPv6 day which describes the upcoming 'test' for the world (and the current 'test page' to check out 'personal' issues at present.)

Share this post


Link to post
Share on other sites

Just bringing over some newsgroup traffic, trplies to some complaints about current problems with IPv6 headder data;

In order to write and test coding for IPv6 parsing and BL operation, the

system had to be made to recognize IPv6. With that done it breaks the

parsing but was an important and needed step for the engineers to work

on IPv6 coding.

There will be a fix but we're still quite a ways off. Part of the

problem is still waiting for standards to be settled.

Richard

Share this post


Link to post
Share on other sites
SpamCop plans to implement support for IPv6 headers later this year.

In the meantime even a local IPv6 address prevents parsing - would it not be appropriate to ignore any purely local IPv6 and complete the parsing based on the public IPv4 address? I have just failed to report a spam of this type.

Share this post


Link to post
Share on other sites
In the meantime even a local IPv6 address prevents parsing - would it not be appropriate to ignore any purely local IPv6 and complete the parsing based on the public IPv4 address? I have just failed to report a spam of this type.

I agree, especially considering there is no public IPv6 address's, everything has to come through an IPv4 gateway someplace.

Share this post


Link to post
Share on other sites

If while during the processing of Received headers a 10.0.0.0/8 address is detected, after a public IP address has been seen, then surely after that any IPv6 headers are moot? No need to extend the software to report such spam.

As already mentioned, all a spammer has to do to evade spamcop reporting is to add a header such as:

Received: from EXIGE.hsc.net.ou.edu ([10.101.1.10]) by

EX-HUB-02.hsc.net.ou.edu ([fe80::7818:b035:6799:d151%10]) with mapi; Thu, 19

May 2011 04:31:36 -0500

The Received header above that is:

Received: from EX-HUB-02.hsc.net.ou.edu (ex-hub-02.hsc.net.ou.edu [10.101.1.13])

by smtp4 (8.14.4/8.14.4) with ESMTP id p4J9VOlQ011352

(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);

Thu, 19 May 2011 04:31:24 -0500

Above that:

Received: from smtp4.ouhsc.edu (smtp4.ouhsc.edu [157.142.11.65]) ...<snip>

Edited by wurtel

Share this post


Link to post
Share on other sites

Just ran into this too, shocked to see that any spammer can prevent reporting by forging a received header with an IPv6 address. Why not, in the short term, only consider received headers up to the first which contains an IPv6 address? It would prevent reporting when the last step went over IPv6, but I expect that's really uncommon. Are you keeping track of how common that is?

Received headers from my failed report: http://www.spamcop.net/sc?id=z5022302439z8...b815b78a60e50bz

Received: from exsmtp3.ntu.edu.sg ([155.69.5.168])
	by host.theinternetco.net with esmtp (Exim 4.76)
	(envelope-from &lt;NEC-RSVN[at]ntu.edu.sg&gt;)
	id 1QRQdJ-0004gY-OQ
	for x; Tue, 31 May 2011 09:13:27 -0600
Received: from EXCHHUB2.staff.main.ntu.edu.sg (155.69.24.24) by
	EXSMTP3.staff.main.ntu.edu.sg (155.69.5.168) with Microsoft SMTP Server (TLS)
	id 8.1.436.0; Tue, 31 May 2011 23:12:58 +0800
Received: from EXCHANGE32.staff.main.ntu.edu.sg ([fe80::a14d:b7e8:6637:5d61])
	by EXCHHUB2.staff.main.ntu.edu.sg ([2002:9b45:1818::9b45:1818]) with mapi;
	Tue, 31 May 2011 23:12:58 +0800

Which looks like a normal final receive by my provider, a normal untrusted receive by a spam relay, and a forged IPv6 receive to prevent reporting.

Share this post


Link to post
Share on other sites

I too am disappointed Spamcop has no provision for IPV6, not even a temporary workaround. Today I got my first one of these and was very surprised to get the Spamcop error that there was "No source IP address found."

Here's the relevant portion of the headers. Here again it might be that the IPV6 was just stuck on to evade Spamcop processing:

Received: from mailgateway.x.com (mailgateway.x.com [192.168.14.70])
	by mail.x.com (Postfix) with ESMTP id 97F6361C19
	for &lt;x[at]x.com&gt;; Sun, 12 Jun 2011 09:40:10 -0500 (CDT)
Received: from lnxms1.twu.ca ([64.114.134.115]:35084)
	by mailgateway.x.com with esmtp (Exim 4.69)
	(envelope-from &lt;Ellen.Wang[at]twu.ca&gt;)
	id 1QVlpg-00061U-1B
	for x[at]x.com; Sun, 12 Jun 2011 09:40:08 -0500
Received: from lnxms1.twu.ca (lnxms1.twu.ca [127.0.0.1])
	by localhost (Postfix) with SMTP id D6C7F4B0803;
	Sun, 12 Jun 2011 07:28:14 -0700 (PDT)
Received: from ES2.twu.ca (es2.twu.ca [10.10.118.65])
	by lnxms1.twu.ca (Postfix) with ESMTP id 75B244B06AA;
	Sun, 12 Jun 2011 07:28:13 -0700 (PDT)
Received: from ES2.twu.ca ([fe80::18e3:7049:2230:c825]) by ES2.twu.ca
 ([fe80::18e3:7049:2230:c825%10]) with mapi; Sun, 12 Jun 2011 07:28:13 -0700

Edited by phantomflash

Share this post


Link to post
Share on other sites

These are becoming a pain.

As received, this spam won't parse;

http://www.spamcop.net/sc?id=z5091666720z9...51babf12dce25az

" Unable to process message. IPv6 addresses are not supported.

No source IP address found, cannot proceed."

But if I delete the apparently spurious ([::ffff:109.233.120.42]) from the 4th "Received" line the message will parse. See

http://www.spamcop.net/sc?id=z5091669646zd...8bda9fc6d512c7z

Note, I did not send the tampered report, this spam simply went unreported.

Share this post


Link to post
Share on other sites

I'd like to second the request to parse the email as it goes, and not bail if a later received header has an IPv6 header in it.

An email I just tried to submit should have been reported to the first received header, even though the second header contains an IPv6 header - you already ignore later headers due to possible forging, it seems like it might be possible to remove the IPv6 check for the potentially forged headers, and then these types of spams would be reported correctly.

Thanks!

Share this post


Link to post
Share on other sites

I'd like to second the request to parse the email as it goes, and not bail if a later received header has an IPv6 header in it.

An email I just tried to submit should have been reported to the first received header, even though the second header contains an IPv6 header - you already ignore later headers due to possible forging, it seems like it might be possible to remove the IPv6 check for the potentially forged headers, and then these types of spams would be reported correctly.

Thanks!

+1 Googleplex! I just had a spam fail to parse for *exactly* this reason! Can we not just ignore IPV6 until such time as they start handing them out? Of course, you should continue working on the IPV6 support code, but don't break parsing just because one INTERNAL handoff in IPV6.

Edited by mrmaxx

Share this post


Link to post
Share on other sites

I just got a spam that SpamCop wouldn't even parse because there was a bogus Received line with an IPv6 address, after ("earlier than") an IPv4 Received line saying from where my Mailhost got the spam: http://www.spamcop.net/sc?id=z5130543490z0...6bdd3878493570z

Share this post


Link to post
Share on other sites

How's the IPv6 support is progressing? Any chance to see sc supporting the format this year?

I cannot report any spam message since the last update.

Share this post


Link to post
Share on other sites

Same as everyone. Getting towards end of year. When will this be fixed?

Is there a way to edit out the ipv6 stuff and re-post the spam?

Share this post


Link to post
Share on other sites
Same as everyone. Getting towards end of year. When will this be fixed?
...See See Don D'Minion's reply in SpamCop article "spam with no originating IP."
Is there a way to edit out the ipv6 stuff and re-post the spam?
...Not that I'm aware. We are prohibited from making "material" changes to spam and IIUC the changes that would be required (removing or changing IP Header lines) violate that policy. I'm afraid you'll just have to ignore those for now.

Share this post


Link to post
Share on other sites
<snip>

Can someone tell me what the ipv6 header is? They look OK to me.

<snip>

...It appears to me that the offending entry is
Received: from localhost ([::1]:53899 helo=mjail0.freenet.de) 
 by mjail0.freenet.de with esmtpa (ID suburbium[at]orenda-dryadis.de) 
 (Exim 4.76 #1)	id 1Rv7Uw-0007Qb-W1; Wed, 08 Feb 2012 14:23:46 +0100

When I remove that line and submit it to the parser, I do not get the error message about IPv6.

Share this post


Link to post
Share on other sites

Getting closer... this was posted in the newsgroups...

---

From: Richard W

Sent: Friday, February 17, 2012 9:48 PM Newsgroups: spamcop Subject: Re: How long do IPv6 spammers get to skate?

IPv6 parsing and reporting support will be in the next maintenance

update (4.7). It's going through QA right now.

Richard

---

Thank you Richard for this update

Share this post


Link to post
Share on other sites

...It appears to me that the offending entry is

Received: from localhost ([::1]:53899 helo=mjail0.freenet.de) 
 by mjail0.freenet.de with esmtpa (ID suburbium[at]orenda-dryadis.de) 
 (Exim 4.76 #1)	id 1Rv7Uw-0007Qb-W1; Wed, 08 Feb 2012 14:23:46 +0100

When I remove that line and submit it to the parser, I do not get the error message about IPv6.

You have some localhost IPv6 header. Here is a teredo IPv6 header that may help in the debugging process:

http://www.spamcop.net/sc?id=z5267442767zf...eac94b71891f3fz

BTW, what else can I do to help get IPv6 support going? It seems that SpamCop has been planning IPv6 support for over two years now.

Share this post


Link to post
Share on other sites
<snip>

BTW, what else can I do to help get IPv6 support going? It seems that SpamCop has been planning IPv6 support for over two years now.

...That's a very good question and one to which I'm sure everyone here wishes she or he knew the answer, so that we all could have taken that step and it would have been done long ago! My naive guess is that SpamCop is working hard to get it right, rather than just throwing out some solution that doesn't work and that it's harder to get it right than anyone thought.

Share this post


Link to post
Share on other sites

...That's a very good question and one to which I'm sure everyone here wishes she or he knew the answer, so that we all could have taken that step and it would have been done long ago! My naive guess is that SpamCop is working hard to get it right, rather than just throwing out some solution that doesn't work and that it's harder to get it right than anyone thought.

You are correct there when we talk about it being harder than we thought. In IPv4 we had periods to divide the octets and colons to separate the port number. We would have been fine if they had kept the same number of colons in IPv6, but they have "allowed" IPv6 to collapse the address. This will make it near impossible to find the address, especially since some mailers put a port number in with the host address, and that means there might be an extra colon and a port number. Tack on top, the idea of the collapsing address and it could change the IP that fast.

Share this post


Link to post
Share on other sites

...That's a very good question and one to which I'm sure everyone here wishes she or he knew the answer, so that we all could have taken that step and it would have been done long ago! My naive guess is that SpamCop is working hard to get it right, rather than just throwing out some solution that doesn't work and that it's harder to get it right than anyone thought.

The "Right" way of doing this would have been to add the IPv6 detection code, and have it log to a file for debugging. This doesn't change the existing behavior from the user perspective.

The detection code should include checks for the IPv6 loopback address [::1], and treat it the same as 127.0.0.1.

The next step would be to add some hooks for each step of the parsing process to call the code, and let it bail out if IPv6 is detected at those points, but you could still do reporting up until the IPv6 handoff, which on all the rejections I have seen, has been on the first or second hop from the sender.

It gets more complicated when the receiving site is running IPv6 internally, or if there is actually IPv6 within the path, but most of the rejections I have seen are either the loopback within an Exchange server, or occasionally a internal handoff within the originating site, or a 6to4 gateway within the originating site.

You parse as far as you can, and include the IPv6 header in the last report.

The wrong way is to simply add a check for IPv6, and puke if found, which is what currently happens, as of the update in March 2011.

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