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]

[I just posted this to the 'New Feature Request' forum, but it seems that link brings you to a forum that is for webmail beta features. I didn't notice that until after I hit send. I think the 'Reporting help' forum is more appropriate for this topic]

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?

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.

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

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?

Yes. Most of the email I get that passes through mx1.freebsd.org is IPv4.

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.

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.

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.

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)

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