Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by ChuckGary61

  1. parenthesis being handshake-kosher or not, Hotmail spam with IPv6 format works!

    "Received: from AM5EUR02HT112.eop-EUR02.prod.protection.outlook.com
     (2603:10a6:3:cf::25) by HE1PR03MB1338.eurprd03.prod.outlook.com with HTTPS
     via HE1P191CA0015.EURP191.PROD.OUTLOOK.COM; Sat, 23 Jun 2018 13:10:24 +0000"

    parses correctly as:

    Report spam to:

    Re: 2603:10a6:3:cf:0:0:0:25 (Administrator of network where email originates)
     To: report_spam@hotmail.com (Notes)

    so WHY doesn't Gmail's IPv6 header spam work? munging headers seems to be much less "kosher", IMO!

  2. 1 hour ago, SpamStoolie said:

    OK, at long last, I took some time to write a version in PHP.

    It works for me. Maybe it will work for you.


    "Sorry, there is a problem

    This attachment is not available. It may have been removed or the person who shared it may not have permission to share it to this location.
    Error code: 2C171/1"

    That's what that link turns up to me.

  3. I just copy/paste the ipv6 into a whois, then copy/paste the resulting ipv4, replacing the ipv6 in the headers - yes it's munging, but it works and like RobieBue says, it amounts to ripping the "ipv6 disguise" off, so in my view, a legit munging. Curiously Hotmail doesn't have this problem, since it puts the ipv6 into a parenthesis that somehow,  the spamcop parser ignores, and thus parses correctly. Again, Spamcop should provide a workaround, like they did for "eudora users" - why not one for "gmail users", Spamcop? 

  4. On 5/21/2018 at 5:16 AM, RobiBue said:

    Unfortunately, SpamCop is currently broken when it comes to some IPv6 addresses in the Received: line(s).

    Since SpamCop is now a subsidiary of Cisco, and part of Talos, I sent them a message, asking them to update the parser to correctly parse private networks through the IPv6 format and especially in the 6to4 ranges. I do not know if this will do any good, but I am hopeful that it will land at someone competent's desk and get implemented soon.

    Someone is misinformed and spreading this misinformation in regard to google and their email header injections.

    Although it is fairly new, ARC headers have been under development since about 2015 and google has been inserting them since mid 2017 without it affecting SpamCop at all, since SpamCop doesn't even check those headers. SpamCop plainly ignores them.

    The problem has been arising since google decided to insert IPv6 6to4 addresses in their Received: lines where it comes to their servers. This, unfortunately, breaks SpamCop and its ability to parse the Received: chain correctly.

    Currently, the only "correct" way to parse spam and submit them without munging or falsifying headers is to convert the IPv6 Received: address which is usually a private network in the range of 2002:a00:: - 2002:aff:ffff:: to the equivalent IPv4 address space of Well, it's still munging/falsifying the headers, but since the IPv6 address is a 6to4 (https://tools.ietf.org/html/rfc3056 and https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml) address, it's basically an IPv4 address in disguise.

    An easy IPv6 to IPv4 translator is http://www.potaroo.net/cgi-bin/ipv6addr.

    I am neither a google employee (although I wouldn't mind) nor am I directly involved with SpamCop (although I have been using it for over 10 years) so I am not the one to talk to either ?

    But as I mentioned earlier, I am hopeful, that someone at Talos will fix the parser to comprehend correctly the IPv6 variant of the IPv4 Private networks.


    I was beginning to think SPAMMERS had found a new way to fool the spamcop parser!

    If spam assumes new formats, spamcop - a paid service - should include adaptations or instructions on how to go around these issues.

    Thank you RobieBue, this worked like a charm.