Jump to content

ipv6


halloween

Recommended Posts

I am starting to get more spam from ipv6 space. It's not a flood yet, but I've noticed it. Maybe 1 in 50 that get through my spam filters is from a spammer in ipv6-land. That is relatively insignificant at the moment, but it's not going to go away.

Is there any ongoing work to make spamcop grok ipv6 addresses?

[The 'New Feature Request' forum appears to be for webmail beta features. I reposted this at the 'Reporting Help' forum. It's probably more appropriate to follow up there. Sorry about the confusion]

Link to comment
Share on other sites

I am starting to get more spam from ipv6 space. It's not a flood yet, but I've noticed it. Maybe 1 in 50 that get through my spam filters is from a spammer in ipv6-land. That is relatively insignificant at the moment, but it's not going to go away.

Is there any ongoing work to make spamcop grok ipv6 addresses?

Link to comment
Share on other sites

I am starting to get more spam from ipv6 space. It's not a flood yet, but I've noticed it. Maybe 1 in 50 that get through my spam filters is from a spammer in ipv6-land. That is relatively insignificant at the moment, but it's not going to go away.

Is there any ongoing work to make spamcop grok ipv6 addresses?

[The 'New Feature Request' forum appears to be for webmail beta features. I reposted this at the 'Reporting Help' forum. It's probably more appropriate to follow up there. Sorry about the confusion]

This is the place for ALL new feature requests. I will be moving the other thread here.

Can you provide a TrackingURL for some of these? I can not ever remember seeing one where the source or remote servers were using IPv6. Everyone I have seen, only the local mail server was using it and converting everything it received to the IPv6 representation.

Link to comment
Share on other sites

Can you provide a TrackingURL for some of these? I can not ever remember seeing one where the source or remote servers were using IPv6. Everyone I have seen, only the local mail server was using it and converting everything it received to the IPv6 representation.

Here's an example that I just resubmitted (I altered the date since the original was from Aug 17 and spamcop rejects messages more than a couple days old):

http://www.spamcop.net/sc?id=z1401588636zc...4935e50837085cz

Link to comment
Share on other sites

Here's an example that I just resubmitted (I altered the date since the original was from Aug 17 and spamcop rejects messages more than a couple days old):

Based on that sample, the real question would be .... do you have any e-mail collected from mx1.freebsd.org that is not showing IPv6 addresses?

Link to comment
Share on other sites

By the way, why is that the real question?

Because that would be the server adding the IPv6 header (at least for that mail route) and would be one path to follow to get your reporting working again.

As I stated earlier, I don't recall ever seeing IPv6 headers on a connecting source, only ones further up the chain.

Link to comment
Share on other sites

Because that would be the server adding the IPv6 header (at least for that mail route) and would be one path to follow to get your reporting working again.

As I stated earlier, I don't recall ever seeing IPv6 headers on a connecting source, only ones further up the chain.

You can't say that anymore, since you've seen one now. ;)

Note that it's not an IPv4 compatible address that was IPv6-ified, but an actual IPv6 address.

Anyway, it's not a lot of spam that does this yet. I have seen a few, so I just thought I'd get the discussion rolling.

Link to comment
Share on other sites

  • 2 years later...

I'm seeing more IPv6 spam lately. These recent ones all come from freenet.de, but it should not be that much work to recognize the received header correctly.

In all of the messages below, the header for the arrival by IPv6 at my system is being ignored, and spamcop begins processing with the next header. Since it seems that freenet.de is adding another valid header when it receives the message, there is something for spamcop to work with, but the assumption that the top header isn't valid is unfortunate.

http://www.spamcop.net/sc?id=z3107858845z1...eb60437ec2b504z

X-First-Received: from 2flagg (2001:748:100:40::2:6)

X-Received-Time: Sat, 11 Jul 2009 21:22:59 -0400 (EDT)

$ host 2001:748:100:40::2:6

6.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout4.freenet.de.

***************

http://www.spamcop.net/sc?id=z3277377851zb...1e8ca75c06488fz

X-First-Received: from 2flagg (2001:748:100:40::2:8)

X-Received-Time: Tue, 1 Sep 2009 05:02:11 -0400 (EDT)

$ host 2001:748:100:40::2:8

8.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout6.freenet.de.

***************

http://www.spamcop.net/sc?id=z3279340826zc...7a6c1eb91472ccz

X-First-Received: from 2flagg (2001:748:100:40::2:5)

X-Received-Time: Wed, 2 Sep 2009 00:13:28 -0400 (EDT)

$ host 2001:748:100:40::2:5

5.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout3.freenet.de.

***************

http://www.spamcop.net/sc?id=z3457351375zf...c7ae5d8c54ea21z

X-First-Received: from 2flagg (2001:748:100:40::2:3)

X-Received-Time: Sat, 31 Oct 2009 10:58:45 -0400 (EDT)

$ host 2001:748:100:40::2:3

3.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout1.freenet.de.

***************

http://www.spamcop.net/sc?id=z3473686828z1...e41259329adc9bz

X-First-Received: from 2flagg (2001:748:100:40::2:6)

X-Received-Time: Fri, 6 Nov 2009 05:54:55 -0500 (EST)

$ host 2001:748:100:40::2:6

6.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout4.freenet.de.

Link to comment
Share on other sites

I'm seeing more IPv6 spam lately. These recent ones all come from freenet.de, but it should not be that much work to recognize the received header correctly.

In all of the messages below, the header for the arrival by IPv6 at my system is being ignored, and spamcop begins processing with the next header. Since it seems that freenet.de is adding another valid header when it receives the message, there is something for spamcop to work with, but the assumption that the top header isn't valid is unfortunate.

As noted, the IPv6 in these cases are being introduced by your (V5.5-11, OpenVMS V8.2 Alpha) machine, the last hop, and is not affecting the parse at all. It would be the same if that were an internal transfer on a 10.x.x.x address.

I doubt we will see much in the way of code changes until we start seeing more problems with parsing, meaning ISP's adopting IPv6 as primary for their networks without IPv4 addresses. It appears freenet.de is connecting to you over IPv6 because your end is capable, but are still using IPv4 internally.

P.S. What Alpha hardware are you running? None of my VMS machines run IPv6. (VAX 7000-630, Alpha 4100, ES40 at work, AlphaStation 4/233 hobby machine at home but not powered on for many months)

Link to comment
Share on other sites

The last header is always introduced by the last machine. But this is not at all the same as if it were an internal transfer on a 10.x.x.x address.

The header is:

Received: from 2flagg (2001:748:100:40::2:6)

by 2flagg.covert.org (V5.5-11, OpenVMS V8.2 Alpha);

Fri, 6 Nov 2009 05:54:55 -0500 (EST)

2001:748:100:40::2:6 is not an internal address; it's the address of the remote machine which relayed the spam to me (mout4.freenet.de). If you don't process that, you don't know that some spammer at 2001:748:100:40::2:6 didn't fabricate the rest of the headers.

The reverse translation (which you ignore anyway when you process headers) is not the actual one due to the fact that I'm running VMS V8.2 on THAT particular machine (and have been since it was installed 4 1/2 years ago: Uptime 1625 21:34:26), an AlphaStation 200 4/233.

My other gateway is running 8.4 (AlphaStation 255/300) and produces headers like this:

Received: from wb2flw.octothorp.org (2001:470:80ee:0:215:c5ff:fe06:ab40)

by covert.covert.org (V5.6-ECO3, OpenVMS V8.3 Alpha);

Sun, 8 Nov 2009 18:00:26 -0500 (EST)

As I'm sure you know, if you don't process the final header, you have no way of knowing for sure that the header before it is valid or not.

Theoretically, my buddy at wb2flw.octothorp.org could be a spammer, and could have created all of the bogus headers before the IPv6. Similarly, unless you actually process the address 2001:748:100:40::2:6 both backwards AND forwards (a spammer could have a bogus reverse translation for his IPv6 origin just like he could for his IPv4 origin), you can't relate it to the other headers.

In the case of the report for message number z3473686828z187e363e622e99ddcfe41259329adc9bz, you trusted the first header beyond the one for the arrival at my machine:

Received: from [195.4.92.12] (helo=2.mx.freenet.de)

by mout4.freenet.de with esmtpa (ID hijgdt[at]bossmail.de) (port 25) (Exim 4.69 #92)

id 1N6MSB-000438-Qz; Fri, 06 Nov 2009 11:54:03 +0100

Fortunately, this one IS an "internal" header added at freenet.de, so the rest of your analysis was OK. If the spammer had connected directly to me, he could have caused the analysis to be wrong, and pointed a spamfinger at someone not even involved, generating a false report.

/john

Link to comment
Share on other sites

  • 1 year later...
  • 3 months later...
Since this was initially requested in 2007... any updates on IPv6? Yesterday I enabled IPv6 on my mailserver and the first spam promptly came in on it. Unfortunately, spamcop claims that it can't handle this sort of spam... annoying!

I am pleased to say that I have managed to be annoying enough that IPv6 for Spamcop is a top priority and work should start late Spring/early Summer.

Link to comment
Share on other sites

  • 1 month later...

Hello all

I think that IPv4-mapped IPv6 addresses [::ffff:w.x.y.z.] may be simple checked or compared with ipv4-only address w.x.y.z?

Example:

Received: from santrex ([::ffff:46.166.137.187])

by smtpsecure.ukzn.ac.za with ESMTP; Thu, 19 May 2011 07:08:23 +0200

Originally this message was not from this host, it's fake 'Recieved' header for protection from antispam filters.

Link to comment
Share on other sites

  • 3 weeks later...

I just got a spam from an external IPv6. Below is what you will see from exim. I suspect that due to IPv6 World Day, we just might starting seeing more of these. This is my second one. I did not think to report my first one that was about five months ago. FYI, tracking link below.

Received: from [2a01:c0:2:dd:21e:c9ff:feff:66d] (helo=Kook.kookhost.com) by kaysville.yaritz.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from <proseguros-insure[at]msn.com>) id 1QWHSC-0005K6-CZ for me[at]yaritz.net; Mon, 13 Jun 2011 18:25:37 -0601

Unable to process header. IPv6 addresses are not supported.

No source IP address found, cannot proceed.

http://www.spamcop.net/sc?id=z5037524167z6...5e80fd223a6f2cz

Link to comment
Share on other sites

  • 3 weeks later...

I've got the same problem with the internal IPv6 handoffs:

Received: from owa10.tccsa.net ([208.108.97.33])
	by redacted with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
	(Exim 4.76)
	(envelope-from &lt;gren_cmiller[at]tccsa.net&gt;)
	id 1QdrID-0007eh-7D
	for redacted; Tue, 05 Jul 2011 00:07:01 +0200
Received: from OWA10.tccsa.net ([fe80::60b0:6f8a:e77c:ea45]) by
 OWA10.tccsa.net ([fe80::60b0:6f8a:e77c:ea45%10]) with mapi id 14.01.0218.012;
 Mon, 4 Jul 2011 18:05:37 -0400

Even though this was sent to me via IPv4, from the IPv4 address of that host (208.108.97.33), SpamCop does not accept the report because they internally handed it off with IPv6 once. (If I were a spammer, I would start to just add fake IPv6 headers to my mails to avoid SpamCop reports....)

I get that SpamCop may have issues tracing actual IPv6 addresses, but why can it not apply the normal IPv4 mailhost rules here?

Link to comment
Share on other sites

  • 2 weeks later...

Here's another email which can't be parsed by Spamcop:

Received: from smtpout1.ucreative.ac.uk ([194.80.225.57])
	by top.qwarx.com with esmtp (Exim 4.75)
	(envelope-from &lt;x&gt;)
	id 1QiXRC-0006mD-3G
	for x; Sun, 17 Jul 2011 20:55:38 +0100
Received: from ul10vn0001.ad.ucreative.co.uk ([10.10.9.8])
	by ud03sr0100.network with esmtp (Exim 4.69)
	(envelope-from &lt;x&gt;)
	id 1QiXO5-0007ed-HD; Sun, 17 Jul 2011 20:52:28 +0100
Received: from UL10BL0008.ad.ucreative.co.uk ([fe80::2830:7d21:fe2f:c006]) by
 UL10VN0001.ad.ucreative.co.uk ([fe80::38ca:abba:dd8a:58e1%13]) with mapi id
 14.01.0218.012; Sun, 17 Jul 2011 20:52:12 +0100

Is there any progress on getting SpamCop to at least not abort in such cases? The IPv6 headers are beyond my registered mailhost, so they would be ignored by SpamCop anyway, if the parsing did not abort.

Cheers, Chris.

Link to comment
Share on other sites

  • 1 month later...

Here's another email which can't be parsed by Spamcop:

Received: from smtpout1.ucreative.ac.uk ([194.80.225.57])
	by top.qwarx.com with esmtp (Exim 4.75)
	(envelope-from &lt;x&gt;)
	id 1QiXRC-0006mD-3G
	for x; Sun, 17 Jul 2011 20:55:38 +0100
Received: from ul10vn0001.ad.ucreative.co.uk ([10.10.9.8])
	by ud03sr0100.network with esmtp (Exim 4.69)
	(envelope-from &lt;x&gt;)
	id 1QiXO5-0007ed-HD; Sun, 17 Jul 2011 20:52:28 +0100
Received: from UL10BL0008.ad.ucreative.co.uk ([fe80::2830:7d21:fe2f:c006]) by
 UL10VN0001.ad.ucreative.co.uk ([fe80::38ca:abba:dd8a:58e1%13]) with mapi id
 14.01.0218.012; Sun, 17 Jul 2011 20:52:12 +0100

Is there any progress on getting SpamCop to at least not abort in such cases? The IPv6 headers are beyond my registered mailhost, so they would be ignored by SpamCop anyway, if the parsing did not abort.

Cheers, Chris.

Exactly....if the first hop beyond the registered mailhost is IPV6, then abort, but if it just contains ONE IPV6 address later in the headers, just process as normal and ignore the IPV6 header until such time as SpamCop is able to process IPV6 addresses!

I just got my first IPV6 address (that I know of...most of the time I quick-report and rarely check the report I get back) and was surprised when I looked at the header that it barfed because the apparent remote mail server received it from an IPV6 address, but sent out via IPV4.

Link to comment
Share on other sites

  • 4 months later...

Thanks for all your ongoing work regarding the IPV6 problem.

From the view of the volunteers who submit their spams, it is frustrating to prepare a submission only to have it kicked out by the SpamCop system at the last step.

Link to comment
Share on other sites

Dear Steve T,

You wrote:

Thanks for the reply and the good link.

I appreciate the opportunity to "add my vote" in favor of getting the ball rolling. We're waiting.

Best luck,

-neil-

Link to comment
Share on other sites

  • 1 month later...

Even though this was sent to me via IPv4, from the IPv4 address of that host (208.108.97.33), SpamCop does not accept the report because they internally handed it off with IPv6 once. (If I were a spammer, I would start to just add fake IPv6 headers to my mails to avoid SpamCop reports....)

I get that SpamCop may have issues tracing actual IPv6 addresses, but why can it not apply the normal IPv4 mailhost rules here?

I'm in the same boat. I don't believe I've actually received any spam via IPv6, but I have had some SpamCop aborts due to IPv6 addresses down in the ignored headers. Simply adding an IPv6 address into your forged header seems like a great way for spammers to exclude their messages from SpamCop reporting. Perhaps that's what it'll take to get SpamCop to change this behavior - a big batch of spammers completely sidelining SpamCop by simply tweaking their fake headers a bit.

Rather than aborting the entire process if an IPv6 address is found anywhere, would it be possible to move the IPv6 check into the per-handoff checking? If an individual server transaction contains an IPv6 address, mark that transaction as unverifiable. However, if the spam source can be found via IPv4 headers well before any IPv6 occurrences, reporting would work as expected. This shouldn't require any additional IPv6 code, but it would result in not failing on emails which contain IPv6 addresses in headers that are ignored anyway.

Link to comment
Share on other sites

<snip>

Perhaps that's what it'll take to get SpamCop to change this behavior - a big batch of spammers completely sidelining SpamCop by simply tweaking their fake headers a bit.

<snip>

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

Archived

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

×
×
  • Create New...