Jump to content
A.J.Mechelynck

Address 2002:adf:aa91:0:0:0:0:0 (gmail) not associated with any of your mailhosts

Recommended Posts

16 hours ago, petzl said:

SpamCop has no trouble with IPv6 It is having trouble Gmails spam sorting ARC "headers" which contain a non-routable IPV6 

Sorry, no! SpamCop is definitely having problems with IPv6.

IPv6 addresses in the 2002:: address range are IP6to4 addresses. This means that if I look up the address that google uses, 2002:ab0:848:0:0:0:0:0 in my case, I get 10.176.8.72. (And now I know where SpamCop got that address from.)

If I replace the IPv6 with the IPv4 respective address in the received line, SpamCop works correctly and gets the correct received line to report the spammer. SpamCop is definitely having trouble with IPv6.

http://www.potaroo.net/cgi-bin/ipv6addr

Try it out and see what SC says if you replace the IPv6 addresses in the received line...

Share this post


Link to post
Share on other sites
8 hours ago, euphorique said:

Hi,

It looks like the address 2002:ab0:11d9:0:0:0:0:0 belongs to Google, yet Spamcop does not list it among the known addresses.

See the problem here: https://www.spamcop.net/sc?id=z6465187313z08acebe658f658913a2727ba46aff928z

Any plans to fix it?

Thank you.

This is becoming a "norm" with Gmail spoofing its own headers?

Cut the spoofing out works fine https://www.spamcop.net/sc?id=z6465265014z6d13dd58c97a050619cabd93381ff7f1z

Share this post


Link to post
Share on other sites
1 hour ago, RobiBue said:

Sorry, no! SpamCop is definitely having problems with IPv6.

IPv6 addresses in the 2002:: address range are IP6to4 addresses. This means that if I look up the address that google uses, 2002:ab0:848:0:0:0:0:0 in my case, I get 10.176.8.72. (And now I know where SpamCop got that address from.)

If I replace the IPv6 with the IPv4 respective address in the received line, SpamCop works correctly and gets the correct received line to report the spammer. SpamCop is definitely having trouble with IPv6.

http://www.potaroo.net/cgi-bin/ipv6addr

Try it out and see what SC says if you replace the IPv6 addresses in the received line...

Just get a non-routable  Gmail network address?
IPv6 Address Report

IPv6Address:   2002:ab0:11d9:0:0:0:0:0
AddressType:   2002:AB0:11D9:: 6to4 address
Subnet48Id:   0 (/48)
InterfaceId:   0:0:0:0
6to4IPv4:   10.176.17.217
Whois:   10.176.17.217

Share this post


Link to post
Share on other sites
47 minutes ago, petzl said:

This is becoming a "norm" with Gmail spoofing its own headers?

Cut the spoofing out works fine https://www.spamcop.net/sc?id=z6465265014z6d13dd58c97a050619cabd93381ff7f1z

I'm not quite sure what you mean by "spoofing". gmail isn't "spoofing" anything. gmail's mail servers are simply inserting their own header information. Spammers "spoof" headers for misinformation or to hide their true address. gmail inserts ARC headers as per IETF's  draft: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol

 

Share this post


Link to post
Share on other sites
58 minutes ago, petzl said:

Just get a non-routable  Gmail network address?
IPv6 Address Report

IPv6Address:   2002:ab0:11d9:0:0:0:0:0
AddressType:   2002:AB0:11D9:: 6to4 address
Subnet48Id:   0 (/48)
InterfaceId:   0:0:0:0
6to4IPv4:   10.176.17.217
Whois:   10.176.17.217

ok, to make it easy to understand:

I have two spam messages that I have parsed (and cancelled) with the original headers:

https://www.spamcop.net/sc?id=z6465270254z4c4075b5ba83cbd2dfbbcd53e1c99bd7z (spam1)

https://www.spamcop.net/sc?id=z6465273727za6eee5107ee00370fef1349a77673e66z (spam2)

both have the Received: by 2002:ab0:848:0:0:0:0:0 line which is actually the IPv6 version of IPv4's 10.176.8.72 address.

This IPv6 address is the problem, as is proven if I replace the IPv6 address with its IPv4 equivalent:

https://www.spamcop.net/sc?id=z6465275148zc4832572efd0c1f3f654be7d8eeea4dbz (spam1)

https://www.spamcop.net/sc?id=z6465275470z63556a2edd51f3ee0847cd3e2e0d8150z (spam2)

but now both spam messages are parsed correctly!

Again, the problem is not the ARC headers. The problem relies solely in the IPv6 capability of SpamCop not being able to parse the IPv6toIPv4 Received: line correctly, and IMNSHO SpamCop needs to fix this.

Share this post


Link to post
Share on other sites
On 5/16/2018 at 6:39 PM, euphorique said:

Hi,

It looks like the address 2002:ab0:11d9:0:0:0:0:0 belongs to Google, yet Spamcop does not list it among the known addresses.

See the problem here: https://www.spamcop.net/sc?id=z6465187313z08acebe658f658913a2727ba46aff928z

Any plans to fix it?

Thank you.

2002:ab0:11d9:0:0:0:0:0 does not "belong" to Google: it is a 6to4 translation of a non-routable IPv4 address. Any IPv6 address whose first 16-bit word is 2002: is an IPv6 translation of an IPv4 address. Which IPv4 address? That can be found by translating, byte by byte, the next two words from hex to decimal: in the present case, if I fill in the high-order zero, 0a b0 and 11 d9, or in decimal 10.176.17.217 — which also, like any IPv4 address in the 10.0.0.0/8 block, belongs to nobody, or to anybody but only for internal use inside a private network but not as an address where something will be sent over the open Internet.

See for instance https://en.wikipedia.org/wiki/6to4#Address_block_allocation

Share this post


Link to post
Share on other sites
50 minutes ago, A.J.Mechelynck said:

2002:ab0:11d9:0:0:0:0:0 does not "belong" to Google: it is a 6to4 translation of a non-routable IPv4 address. Any IPv6 address whose first 16-bit word is 2002: is an IPv6 translation of an IPv4 address. Which IPv4 address? That can be found by translating, byte by byte, the next two words from hex to decimal: in the present case, if I fill in the high-order zero, 0a b0 and 11 d9, or in decimal 10.176.17.217 — which also, like any IPv4 address in the 10.0.0.0/8 block, belongs to nobody, or to anybody but only for internal use inside a private network but not as an address where something will be sent over the open Internet.

See for instance https://en.wikipedia.org/wiki/6to4#Address_block_allocation

this is nonsensical spam filtering jargon (spoof) that Gmail now adds to it's headers. Has nothing to do with received email headers, then next week Gmail are likely to change it again, The "ARC" filtering has nothing to do with anyone but Gmail. They are not genuine recieved headers.

Share this post


Link to post
Share on other sites

spam filtering jargon or internal handoff, be that as it may; in any case that line holds no more spam-tracking information than any (let's say) 10.20.30.40 IPv4 Received-line. The parser skips the latter, IMHO it ought likewise to skip the equivalent 2002:a14:1e28::

Or is Google really a black-hat ISP, trying all possible ways (and at times succeeding) to thwart SpamCop and let spammers have the run of the town?

Best regards, Tony.

Share this post


Link to post
Share on other sites
1 hour ago, petzl said:

this is nonsensical spam filtering jargon (spoof) that Gmail now adds to it's headers. Has nothing to do with received email headers, then next week Gmail are likely to change it again, The "ARC" filtering has nothing to do with anyone but Gmail. They are not genuine recieved headers.

...nonsensical, spoof, whatever you would like to call it... SpamCop is still not parsing the ARC headers... because for SpamCop they are irrelevant (at least for the time being)

SpamCop is just plain not parsing correctly the IPv6 Received: line returned by the last mail server, regardless of ARC, SPF, DKIM, DMARC header insertion or not.

Share this post


Link to post
Share on other sites

Again, the Gmail ARC headers have nothing to do with finding anything. They are just stamping Gmail gibber that sorts spam from ham through Gmail servers. One has the option to go through the headers and report Gmail spam themselves , or remove the ARC spam headers and feed them into SpamCop. If SpamCop can work out how to ignore these " Gmail ARC headers" yes it would make life easier! 

Share this post


Link to post
Share on other sites
6 hours ago, A.J.Mechelynck said:

spam filtering jargon or internal handoff, be that as it may; in any case that line holds no more spam-tracking information than any (let's say) 10.20.30.40 IPv4 Received-line. The parser skips the latter, IMHO it ought likewise to skip the equivalent 2002:a14:1e28::

Or is Google really a black-hat ISP, trying all possible ways (and at times succeeding) to thwart SpamCop and let spammers have the run of the town?

Best regards, Tony.

Just some pointy-head idea that Gmail now stamps on top of real received email headers. The gobbledygook explanation I got from Gmail is that it's Gmail's spam from ham sorting header, which may or may not mean something to Gmail but to no one else. I don't think Gmail worries about SpamCop problems, I do know if you don't kill spammers and your spam box gets a "high" quota of spam, Gmail will close your account. SpamCop is the most effective method of killing spammers.

Edited by petzl

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

×