Jump to content

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

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

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

 

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

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

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

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

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

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

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

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...