Jump to content

IPv6 Routing Support


SpamCopAdmin

Recommended Posts

  • 2 months later...
  • Replies 83
  • Created
  • Last Reply

Top Posters In This Topic

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.

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

Link to comment
Share on other sites

  • 4 weeks later...

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

Link to comment
Share on other sites

  • 2 weeks later...
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.

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

Link to comment
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
Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

  • 2 weeks later...

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
Link to comment
Share on other sites

  • 2 months later...

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.

Link to comment
Share on other sites

  • 4 weeks later...

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!

Link to comment
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
Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

  • 1 month later...

I too just had an email that SpamCop spit back & said there was no source IP so it couldn't continue: http://www.spamcop.net/sc?id=z5163609103zd...ede547e869ebbdz

I think it's tripping over the IPv6 header. I know it skips the 172.x.x.x header (internal IP) and should also ignore the 10.x.x.x IP header as well.

The other Received headers seem fine.

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...
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.
Link to comment
Share on other sites

  • 1 month later...
<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.

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

  • 2 weeks later...

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

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

Link to comment
Share on other sites

  • 1 month later...

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...