ipv6 still unsupported?

[A.J.Mechelynck]

How do I register an ipv6 mailhost?

Trying to parse https://www.spamcop.net/sc?id=z6437551039z397c7682b607208ad3137a9ddf74157ez

 

host 2002:a17:902:6881:0:0:0:0 (getting name) no name

0: Received: by 2002:a17:902:6881:: with SMTP id i1-v6mr7121788plk.323.1516767567431; Tue, 23 Jan 2018 20:19:27 -0800 (PST)

No unique hostname found for source: 2002:a17:902:6881:0:0:0:0

Possible forgery. Supposed receiving system not associated with any of your mailhosts

Will not trust this Received line.

Mailhost configuration problem, identified internal IP as source

Mailhost:
Please correct this situation - register every email address where you receive spam

No source IP address found, cannot proceed.

[A.J.Mechelynck]

P.S. This seems related to the following topic:

 

[Magna atque magnifica Oz]

3 hours ago, A.J.Mechelynck said:

How do I register an ipv6 mailhost?

Trying to parse https://www.spamcop.net/sc?id=z6437551039z397c7682b607208ad3137a9ddf74157ez

 

host 2002:a17:902:6881:0:0:0:0 (getting name) no name

This seems to be a problem within Spamcop and not a question of registering the mailhost.

The thing is 2002:a17:902:6881:0:0:0:0 is not a valid ipv6 address and never will be. The 2002 range is reserved for transitioning between ipv6 and ipv4. The 2002 is a flag value followed by the ipv 4 address (a17:902) and the following 6881 is a subnet address. In this case, the ipv4 address works out to 10.23.9.2, which is the Internet Assigned Numbers Authority (IANA).

I believe that if you look at the headers of any of your other gmail messages, you'll find that any X-Received line that doesn't start with 2002: will start with 10. As far as I can tell, it's something that Gmail uses internally and has nothing to do with the email source.

With the ongoing transitioning to ipv6, this issue is likely to pop up more often. Unfortunately there seems to be nothing that we users can do until the people at Spamcop tweak the parser to deal with these 2002 range addresses.

FYI: The actual IP that your spam came from was 113.23.219.233 which is located in Malaysia. It's starting to look like all these errors are occurring when Gmail receives spam from Asian countries along the Pacific coast.

[A.J.Mechelynck]

18 minutes ago, Magna atque magnifica Oz said:

This seems to be a problem within Spamcop and not a question of registering the mailhost.

The thing is 2002:a17:902:6881:0:0:0:0 is not a valid ipv6 address and never will be. The 2002 range is reserved for transitioning between ipv6 and ipv4. The 2002 is a flag value followed by the ipv 4 address (a17:902) and the following 6881 is a subnet address. In this case, the ipv4 address works out to 10.23.9.2, which is the Internet Assigned Numbers Authority (IANA).

I believe that if you look at the headers of any of your other gmail messages, you'll find that any X-Received line that doesn't start with 2002: will start with 10. As far as I can tell, it's something that Gmail uses internally and has nothing to do with the email source.

With the ongoing transitioning to ipv6, this issue is likely to pop up more often. Unfortunately there seems to be nothing that we users can do until the people at Spamcop tweak the parser to deal with these 2002 range addresses.

FYI: The actual IP that your spam came from was 113.23.219.233 which is located in Malaysia. It's starting to look like all these errors are occurring when Gmail receives spam from Asian countries along the Pacific coast.

I still have that spam somewhere on my HD.

I suppose that cutting away that first 10.x.x.x Received-line and what follows it (including the ipv6 X-Received line) until, but not including, the next Received-line, which says (as the parser displays it)

Quote

Received: from birdol.mudsuccess.com (birdol.mudsuccess.com. [113.23.219.233])
        by mx.google.com with ESMTPS id e3-v6si5588972plk.542.2018.01.23.20.19.26
        for <x>
        (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
        Tue, 23 Jan 2018 20:19:27 -0800 (PST)

might let SpamCop parse the email; but OTOH "tampering" with spam in that kind of way is supposed to be frowned upon, to say the least; so I wonder what I could do, if anything.

 

Best regards,

Tony.

[Magna atque magnifica Oz]

14 hours ago, A.J.Mechelynck said:

I suppose that cutting away that first 10.x.x.x Received-line and what follows it (including the ipv6 X-Received line) until, but not including, the next Received-line, which says (as the parser displays it)

might let SpamCop parse the email; but OTOH "tampering" with spam in that kind of way is supposed to be frowned upon, to say the least; so I wonder what I could do, if anything.

Actually, it's this line that's the crux of the problem: X-Received: by 2002:a17:902:6881:: with SMTP id i1-v6mr7121788plk.323.1516767567431; Tue, 23 Jan 2018 20:19:27 -0800 (PST)

If you were to cut it out, then I'm sure the parser would work properly. But, as you pointed out, that's a no no, which is why I didn't suggest it in the first place. I don't even know why that line is parsed because X-Received is non-standard and somewhat untrustworthy.

Until some action is taken by Spamcop, there's nothing we can do.

[gnarlymarley]

I just realized something.  It seems that the parse is taking the X-Received line and treating it as a Received line.  Probably someone did a coding change and didn't have their parser start at the beginning of the line.

X-Received: by 2002

0: Received: by 2002

 

[petzl]

9 hours ago, gnarlymarley said:

I just realized something.  It seems that the parse is taking the X-Received line and treating it as a Received line.  Probably someone did a coding change and didn't have their parser start at the beginning of the line.

X-Received: by 2002

0: Received: by 2002

 

First thought it was Gmail that had a mis configured server! it is not the spammer has re-named it's computer with fake headers (normally named "My Computer")

https://www.spamcop.net/sc?id=z6439106688ze2085fa996031bee97c9833bf4392f10z

X-Google-Smtp-Source: AH8x224uqG6EmUcfBYgUUgeXFVG8X7M7w5W/y8cGQeu6qelGfT+SEvNeSkl7OwtDDHo5q1hWz5kT
X-Received: by 2002:a17:902:7c95:: with SMTP id y21-v6mr18271267pll.243.1517248215276;
        Mon, 29 Jan 2018 09:50:15 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1517248215; cv=none;
        d=google.com; s=arc-20160816;
        b=rEEv75F5u0pdFSKOVadtEjk7uJrCHelc0PyQpdByEDyjWWjuZAdEQzdbZas46sOavz
         uq51pjdot+3JquNVN0ArIXIeJJew2WImCbj67CeH8ko2enKHNcnHlQ1EJDdViFjkCSvW
         h3yeMgOFqQvdv+kwXc+DD2D/1dVJgtV+zRwqNxbf6l3XouOpPm9OAvSBe1LxCIl4+801
         RhuvHrHmUiE/o/4qBrkkG98sZu/st4ucNXuFjBeFuIGOylzcgjk54wbEURsV6ln/17pW
         n98BWquLG8kkXQdrvDvlSVhJX/6J7oqN2iar7/rKIoeAnaS0jFjkkBMarB/vhun3z0MW
         bhVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:mime-version:subject:message-id:reply-to
         :from:date:arc-authentication-results;
        bh=+eTI5hmwWM+vKJlIEYpqSa+SlkHtoDA4l9SsJgC1tGw=;
        b=hOw+HMMu1x1S7eUFnQM79pTuWFRcJBn4lEk/FyRJpWis8wxd8RSwrd1qqwME2N+mob
         Hi35I+9CK7jjE3se5bTIjjgs/phnbdSv/5sIymQuFxTOLWPwNK2WR2luHKc0Rf2PpqT3
         BepCqTZ7svwzP1ft10n4kUJxpwJDe3ZHRZ/9GsJZfibirT/TT9O+3yEdwn3+8ZHmWwsp
         EmhUGPM4kjpNy37Whc8gs+Lzlkgxqs+FfEAe+vBXLCOE5vj50tkwys2YYc3dnFsluIGy
         TT25JEqtd1iaFeQcYHuvN2AJkwOQfwgFeXg1hkdPTtRLAzDSElyMbEYK+B1yCmQ7bLXy
         pyYA==

For SpamCop parser to report this you have to snip it out?
Put fake headers in the submit "notes" which are

https://www.spamcop.net/sc?id=z6439116336z607dabe7cb156e8f3743b8d25d345f64z

[A.J.Mechelynck]

Cut away all this stuff from the top of the header part and paste it back into the "user comments" box on the "parse results" page, is that it? Well, if you say so…

 

Best regards,

Tony.

[petzl]

2 hours ago, A.J.Mechelynck said:

Cut away all this stuff from the top of the header part and paste it back into the "user comments" box on the "parse results" page, is that it? Well, if you say so…

 

Best regards,

Tony.

I have, but you can also report it from your email account

[A.J.Mechelynck]

47 minutes ago, petzl said:

I have, but you can also report it from your email account

Even if I report it by attaching it to an email to my SC reporting address, I would still have to cut those lines away before sending the email and paste them back below the corresponding parse, wouldn't I? In such a case, pasting the rest of the spam on the reporting page and the offending lines almost immediately afterwards below the parse seems less error-prone to me.

 

Best regards,

Tony.

[petzl]

1 hour ago, A.J.Mechelynck said:

Even if I report it by attaching it to an email to my SC reporting address, I would still have to cut those lines away before sending the email and paste them back below the corresponding parse, wouldn't I? In such a case, pasting the rest of the spam on the reporting page and the offending lines almost immediately afterwards below the parse seems less error-prone to me.

 

Best regards,

Tony.

You can forward as attachment from Gmail to the relevant abuse address  just click "Show original" in Gmail and they will show the IP it was sent from

[Lking]

Please read ipv6 Routing Support pinned above.

[A.J.Mechelynck]

12 minutes ago, Lking said:

Please read ipv6 Routing Support pinned above.

I did just now. That thread was started 2011-02-10 and its last post, dated "Edited 2013-02-13", says that SC version v4.7.0.111 (and higher, I suppose) supports IPv6. Today SC boasts v4.8.7 but I still got problems a few days ago with an email sent to my @gmail.com account and which had, first, a "Received:" line with a 10.x.x.x address, and just below ("earlier") an "X-Received:" line with an IPv6 address. From petzl's experiments, it seems that the spam will be parsed correctly if these two lines, and a few non-"Received:" lines below them, are snipped away before reporting.

12 hours ago, petzl said:

You can forward as attachment from Gmail to the relevant abuse address  just click "Show original" in Gmail and they will show the IP it was sent from

Yes, yes, but if there is an IPv6 X-Received line near the top of the headers I will still have to snip it away before sending the spam to SC or the parse will fail. I know I can send one or more spam messages to SC together by attaching them to an email to my SC reporting address, but SC will present them to me one by one, each on its own parse page. Of course if I must paste back the snipped lines into the "User comments" box, I have to do it on the right parse page, and for that I have to identify it. In order to avoid pasting the offending lines into the wrong reports page, it seems simpler to me to simply make sure that I have no queued spam left to report, then click "Save to clipboard" on the right side of Google's "Show original" page (after scrolling horizontally if necessary) then paste into the SC reporting page, but "Cut" the offending lines before sending (to avoid a parsing failure) and immediately afterwards paste them back in the first "User comments" box below the paste, possibly prefixed by "[The following lines were snipped from the top headers of the spam to avoid a spamcop malfunction]" or something similar.

[petzl]

56 minutes ago, A.J.Mechelynck said:

Yes, yes, but if there is an IPv6 X-Received line near the top of the headers I

They are not IPv6 they are bogus "2002:a17:902:7c95 is not a routeable IP address"

[A.J.Mechelynck]

24 minutes ago, petzl said:

They are not IPv6 they are bogus "2002:a17:902:7c95 is not a routeable IP address"

Well, then, "if there is a bogus-IPv6 X-Received line", etc.

[gnarlymarley]

Another note is that not all gmail message have that header with an IPv6 address.  Some have it with a actual IPv4 address.  I wonder if they are testing or trying something.  Anyhow, I do find it interesting that spamcop accepts the non-routeable IPv4 address as local in its headers, but not the non-routeable IPv6 address, which is in the same exact location in the headers.

X-Received: by 10.31.219.6 with SMTP id

 

[A.J.Mechelynck]

2 hours ago, gnarlymarley said:

Another note is that not all gmail message have that header with an IPv6 address.  Some have it with a actual IPv4 address.  I wonder if they are testing or trying something.  Anyhow, I do find it interesting that spamcop accepts the non-routeable IPv4 address as local in its headers, but not the non-routeable IPv6 address, which is in the same exact location in the headers.

X-Received: by 10.31.219.6 with SMTP id

 

Indeed. Of the spam I get, most have that X-Received: 10.something (i.e. IPv4 unroutable) line, and SpamCop has no problem with them. Now and then, I get one with an X-Received: 2002:something (IPv6 unroutable) and SpamCop can only process those spam messages if I snip away that line (there was one such earlier today but IIRC it was the first one after the one which made me start this thread).

I note that two lines above that X-Received line (of either kind) there is a Received line which is always in unroutable IPv4 format. Don't know if relevant.

 

Best regards,

Tony.

[Magna atque magnifica Oz]

On 1/30/2018 at 1:29 PM, petzl said:

They are not IPv6 they are bogus "2002:a17:902:7c95 is not a routeable IP address"

Well, not exactly bogus, but not a routeable IP address either. The 2002 range was reserved for IPv4 tunneling. The two 16-bit numbers following the 2002 represent the IPv4 address with the last 16-bit number being a subset on that address. So 2002:a17:902:xxxx translates to: 0a.17.09.02 or in decimal 10.23.9.2, which is also a non-routeable address. My best guess is that Gmail is using these 10.xxx.xxx.xxx addresses to internally route emails through their network.

If you're interested, just do a search on the term 6to4 for more information on this tunneling thing, reviews from people who find it a pain in the neck, along with others who have a much lower opinion of it.

[petzl]

they are bogus headers, which need deleting for SpamCop to report. SpamCop can identify IPv6 

Delivered-To: X
Received: by 10.100.130.70 with SMTP id t6csp7709755pje;
        Wed, 31 Jan 2018 15:55:56 -0800 (PST)
X-Google-Smtp-Source: AH8x225I6CPP8Vv2dXBC4Jugoj+ReQm7+0XTvtXVPby55TryGxiUtmEKVhiubPZ3fnlNPjyNhQc6
X-Received: by 10.99.44.209 with SMTP id s200mr1200255pgs.407.1517442955995;
        Wed, 31 Jan 2018 15:55:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1517442955; cv=none;
        d=google.com; s=arc-20160816;
        b=KmkrHOx6aPnleROMzvB3DudGp7VKoyOUS5qS9iAYFMSMrvJdRtoqtXna+iYTsNKYQ7
         IYkk9XOHiXWgTTeX+zb+t5qp/6O/Q6MSxEOyx83k3xvOvGD2A7HJ6VkaA4C37a7rV/jr
         ENBbqH4rp4PKxKTeeaJfZP9oTsb/sq1iQMThgsPLskUEaJt+3Uo+jyGIQlkFc9munVJD
         iH4b7ZUYOirs45kTImWBLV7scDnbV0VIj6hXCJR4g3X7ZD+t+8O82QVMbnDDWoZbIuuz
         OdcPO4xXTguIp98ZR+k4AxnDCNmIzkLy2codg6iKCyYrY164p7gJecnur2LX/32iBRf4
         OoaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=date:message-id:content-transfer-encoding:mime-version:reply-to
         :from:subject:to:dkim-signature:arc-authentication-results;
        bh=J/l6ulHkhwVGqj8f17rpm6+MY720oUQuASZ7qZoM9Vg=;
        b=Abo5taLKxCYYB6QeVETQkGvf/OKCDyl7zYtFQ6BEfLgcuGD+d4E+C3hhuDJDAxfOE5
         JyvdIkkx+TTOAdmaer0jMigz1j8KrxjI+w+l9PjoUcfYNOQlCwAe7ZWi3Lj7IR0K+k1/
         Z8nXMd4CaskeY/WSijkNgbeF73hkEJ0iwsU74sLU6xJ55LA4wRKnETwhXyDVI2x6Cl9y
         aFeOJgkFnqKihILrFWJjUl9KlhHMmey6PuWfeIvsWhI/6anf97UYrEJMFlSml6hWmKQA
         VVvyIQhirrtfW6Ngr/K975510ZvstoHEGE6cx+4JU7wRh3WBt1PFa2Zq3sL4P2658zcV
         /Qwg==

Just include them in notes

headers reported  https://www.spamcop.net/sc?id=z6440769324zb77944826b82dd3c90873e053b71b743z

[A.J.Mechelynck]

6 hours ago, petzl said:

they are bogus headers, which need deleting for SpamCop to report. SpamCop can identify IPv6 

Delivered-To: X
Received: by 10.100.130.70 with SMTP id t6csp7709755pje;
        Wed, 31 Jan 2018 15:55:56 -0800 (PST)
X-Google-Smtp-Source: AH8x225I6CPP8Vv2dXBC4Jugoj+ReQm7+0XTvtXVPby55TryGxiUtmEKVhiubPZ3fnlNPjyNhQc6
X-Received: by 10.99.44.209 with SMTP id s200mr1200255pgs.407.1517442955995;
        Wed, 31 Jan 2018 15:55:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1517442955; cv=none;
        d=google.com; s=arc-20160816;
        b=KmkrHOx6aPnleROMzvB3DudGp7VKoyOUS5qS9iAYFMSMrvJdRtoqtXna+iYTsNKYQ7
         IYkk9XOHiXWgTTeX+zb+t5qp/6O/Q6MSxEOyx83k3xvOvGD2A7HJ6VkaA4C37a7rV/jr
         ENBbqH4rp4PKxKTeeaJfZP9oTsb/sq1iQMThgsPLskUEaJt+3Uo+jyGIQlkFc9munVJD
         iH4b7ZUYOirs45kTImWBLV7scDnbV0VIj6hXCJR4g3X7ZD+t+8O82QVMbnDDWoZbIuuz
         OdcPO4xXTguIp98ZR+k4AxnDCNmIzkLy2codg6iKCyYrY164p7gJecnur2LX/32iBRf4
         OoaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=date:message-id:content-transfer-encoding:mime-version:reply-to
         :from:subject:to:dkim-signature:arc-authentication-results;
        bh=J/l6ulHkhwVGqj8f17rpm6+MY720oUQuASZ7qZoM9Vg=;
        b=Abo5taLKxCYYB6QeVETQkGvf/OKCDyl7zYtFQ6BEfLgcuGD+d4E+C3hhuDJDAxfOE5
         JyvdIkkx+TTOAdmaer0jMigz1j8KrxjI+w+l9PjoUcfYNOQlCwAe7ZWi3Lj7IR0K+k1/
         Z8nXMd4CaskeY/WSijkNgbeF73hkEJ0iwsU74sLU6xJ55LA4wRKnETwhXyDVI2x6Cl9y
         aFeOJgkFnqKihILrFWJjUl9KlhHMmey6PuWfeIvsWhI/6anf97UYrEJMFlSml6hWmKQA
         VVvyIQhirrtfW6Ngr/K975510ZvstoHEGE6cx+4JU7wRh3WBt1PFa2Zq3sL4P2658zcV
         /Qwg==

Just include them in notes

headers reported  https://www.spamcop.net/sc?id=z6440769324zb77944826b82dd3c90873e053b71b743z

In the case displayed here, the X-Received line is just as bogus, but it is in IPv4 format, and in this case SpamCop doesn't choke on it. What puzzles gnarlymarley and me is that it's only when that bogus X-Received line is in IPv6 format (a relatively rare case at the moment, in my experience, but of course you never know what tomorrow will bring) that it makes the SpamCop parse end in error.

As a "request for enhancement", would it be to much to ask the SpamCop parse engine to bypass non-routable IPv6 addresses like it already bypasses non-routable IPv4 addresses? Or maybe to bypass X-Received lines altogether?

[petzl]

13 hours ago, A.J.Mechelynck said:

As a "request for enhancement", would it be to much to ask the SpamCop parse engine to bypass non-routable IPv6 addresses like it already bypasses non-routable IPv4 addresses? Or maybe to bypass X-Received lines altogether?

One can try. Seems to me SpamCop reporting does not have a very high priority. Reports are still sending URL link to dead end example

117.62.3.111 is open proxy, see: https://www.spamcop.net/mky-proxies.html

Every so often send yourself a copy. At present hammering Chinese spam slowly seem to be having an effect?

[A.J.Mechelynck]

1 hour ago, petzl said:

One can try. Seems to me SpamCop reporting does not have a very high priority. Reports are still sending URL link to dead end example

117.62.3.111 is open proxy, see: https://www.spamcop.net/mky-proxies.html

Every so often send yourself a copy. At present hammering Chinese spam slowly seem to be having an effect?

Chinese spam? What Chinese spam? The access providers from which I see a lot of spam at the moment are:

• 1and1.com
• amazonaws.com
• Internal spamcop handling (bt)
• ovh.net
• hetzner.de

Others come far behind, and they all speak English (though at times broken English, as in "Your parcel might arrived"). Some years ago I used to get a lot of Korean spam but that seems to have totally disappeared.

[A.J.Mechelynck]

P.S. Anyway, like Miss Betsy used to say, fighting spam is like busting molehills, it's a never-ending battle.

Best regards,

Tony.

[petzl]

4 hours ago, A.J.Mechelynck said:

P.S. Anyway, like Miss Betsy used to say, fighting spam is like busting molehills, it's a never-ending battle.

And she is still right

All the best Petzl

[A.J.Mechelynck]

Experiment shows that removing only the "X-Received: by 2002: (etc.)" line ("line" in email headers sense of course, i.e. including any indented continuation lines following it) is enough to make SpamCop parse the spam with no error. (Then I paste the removed line back, of course, into the first "user comments" box at the end of the parse page.)

 

Best regards,

Tony.