RobiBue Posted May 16, 2018 Share Posted May 16, 2018 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 More sharing options...
petzl Posted May 17, 2018 Share Posted May 17, 2018 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 More sharing options...
petzl Posted May 17, 2018 Share Posted May 17, 2018 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 More sharing options...
RobiBue Posted May 17, 2018 Share Posted May 17, 2018 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 More sharing options...
RobiBue Posted May 17, 2018 Share Posted May 17, 2018 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 More sharing options...
A.J.Mechelynck Posted May 18, 2018 Author Share Posted May 18, 2018 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 More sharing options...
petzl Posted May 18, 2018 Share Posted May 18, 2018 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 More sharing options...
A.J.Mechelynck Posted May 18, 2018 Author Share Posted May 18, 2018 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 More sharing options...
RobiBue Posted May 18, 2018 Share Posted May 18, 2018 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 More sharing options...
petzl Posted May 18, 2018 Share Posted May 18, 2018 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 More sharing options...
petzl Posted May 18, 2018 Share Posted May 18, 2018 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.