Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by RobiBue

  1. Since mid-May I have been reporting spam originating from IP-range 58.14/16

    May 18, 2018 - June 29, 2018 total of 3359 spam messages from that IP range! That's over 76 per day...

    It looks like my reporting is working, as the spammer seems to be switching to 27.146/16 as I have already received 10 from there in the last 1.5 hour...

    Unfortunately, Cloudflare is still hosting their spamvertised websites... and doesn't seem to give "a barrier constructed to hold back water"

  2. I stand corrected... I tried the first URL (rli4agdrppbmldbtnmctdvkaorftbetr) and that one returned nothing, then I tried the last one (whitefide) with the same result...

    then I tried the obvious un-subscribe one where I assumedthe others ending with TLD .pw would be like the first one, sorry.

    Then, I don't know why it would not parse them from the original...

  3. 12 minutes ago, euphorique said:


    The parser could not find a single link. Any reason for that?


    Hello Euphorique,

    the reason that SC doesn't find any links is, that there are no links in the spam.

    Although the list of "websites" looks like links, it's just plain text.

    If you try to resolve one or more of them manually (by pasting the link in the parser field and press the [ Process spam ] button, you will see that they are fake anyway ;)

    except for one, but I'll assume that it's an innocent site...

  4. 1 hour ago, albert2 said:

    Thanks Petzl,

    Seems you have pinpointed the problem to the second header line.

    Do you or someone else knows what exactly is caused by this line & what this line tells ?

    Again maybe Spamcop systems can be altered to remove or ignore this line automatically when present so users won't need to take care of it anymore for each mail.

    If this line is specific to mailboxes from gmail, maybe spamcop could contact google and ask for a solution.



    The line tells that the message was received by the mail server at IPv6 address 2002:a9d:21b7:0:0:0:0:0 which is actually a 6to4 address translated from the IPv4 address

    In short, the mail server at google that received the message before displaying it to you in your gmail account has the IP address

    I received the following message from SpamCop:

    Gmail has broken their headers, not showing who received the mail and
    using IP addresses that do not resolve.

    Google has promised to fix the issue but have not provided an ETA of a
    fix.  We looked at programming around it but that option was rejected by
    our CERT board as it would have opened a security hole in our system.

    We can just sit and wait for Gmail.



  5. 40 minutes ago, halberstadt said:

    Thanks, petzl.  

    As I understand, we should edit the raw "headers plus text" before submitting, to delete its second line (similar to above example). I don't understand, however, "...ISP's need FULL headers as evidence so past deleted line in comments".

    Bill Halberstadt

    yeah, that's right, they need the full headers, but the problem is within SpamCop, where the parsing of said Received: line causes havoc within the next (previous actually) Received: lines.

    The 2002:a02:b4d7:0:0:0:0:0 address is called a 6to4 address, but according to RFC-3056, section#2:

    [A] subscriber site has at least one valid, globally
    unique 32-bit IPv4 address, referred to in this document as V4ADDR.
    This address MUST be duly allocated to the site by an address
    registry (possibly via a service provider) and it MUST NOT be a
    private address [RFC 1918].

    and Google is inserting their private addresses into the IPv6 6to4 address. That would in fact be a violation of the aforementioned RFC-3056 as :a02:b4d7: translates to which is definitely a private address according to RFC-1918, section#3.

    In theory, they should (if they want to use private IPv6 addresses) use, according to RFC-4193, section#3, addresses in the fc00::/7 or fd00::/8 address ranges. Unfortunately SpamCop has the same problem with the fd00:/8 addresses and does not identify those addresses as local private addresses like the 10/8, 172/12, and 192.168/16 address ranges.

    I have written a crude program that replaces the 6to4 addresses with the actual IPv4 counterpart and places the original IPv6 address in parentheses. The program works for me, but I have not tested it with a larger group of gmail users, and am reluctant to do so, as munging headers is mostly a "no-no" and could cause SpamCop to disable user accounts, although this type of munging is necessary for SpamCop to correctly identify the actual spammer (or the proxy they are using).

    Until SpamCop gets an update to correctly identify those IPv6 addresses as local/private addresses, the aforementioned removal or change of the address is necessary to get SpamCop to work correctly with gmail accounts.

    To add some workarounds:

    • remove the topmost Received: line with the address beginning with 2002:a
    • or change the address beginning with 2002:a to its IPv4 address using http://www.potaroo.net/cgi-bin/ipv6addr
    • or replace the address beginning with 2002:a with mx.google.com

    I have seen these three options in action before, and they work.



  6. https://www.spamcop.net/sc?action=showroute;ip= points to:

    Reports routes for
    routeid: 71622013 - to: abuse@nobistech.net
    Administrator found from whois records
    routeid: 71622026 - to: abuse@nobistech.net
    Administrator interested in all reports
        12/3/2013, 4:25:50 PM -0600
        [Note added by (63-224-241-72-boi-usr.qwest.net)]
        Per RIPE
        - Don -
    This is not correct anymore and should be changed (the above address bounces anyway)
    has two abuse addresses:
    abuse@noc4hosts.com, and abuse@hivelocity.net

  7. 4 hours ago, RJVB said:

    Well, it shouldn't be. That's like plugging holes in the ceiling instead of getting the upstairs neighbour to repair the leak in his plumbing. As long as there are things to spamvertise the spam will keep coming.


    I understand the frustration, and I do have the same point of view, although I do admit that the reason of the lowest priority is that many spammers use legit links that will clog abuse mailboxes from these legit ISPs.

    as an example (although I haven't had one recently) spammers have added "terms of conduct" and similar links from 3rd party ISPs which SC will use to send reports to them.

    Also, random images found on the internet either akamaized or from other providers have been used as links before (although these IIRC have been since disabled by SC)

  8. 26 minutes ago, lepa71 said:

    I don't think it's confusing. It is exactly @RobiBue is saying.

    Here is another one.


    Maybe another confusion is. IS the  2002:a9f:3d14:0:0:0:0:0 full IPv6 or google strips it? I don't think those 0:0:0:0:0 should there that way.


    @ Lking: I did read the contents carefully :) but I also noticed the coincidental appearance of the same IP address in both header and body which only means to me, that the spammer is advertising from his own IP address.
    If I had a mail server and a web server on my network, and I would be sending mail form my mail server with links to the website on my web server, both mail server and web server addresses would have the same IP address.

    @ lepa71: the IPv6 address 2002:a9f:3d14:0:0:0:0:0 is a correct 6to4 IPv6 address and can be abbreviated as 2002:a9f:3d14:: or expanded to 2002:0a9f:3d14:0000:0000:0000:0000:0000
    They all mean the same and all point to the IPv4 IP address [] (you can try them here and see the result.)

    I have seen in past reports (besides my own) that google's mx servers utilize various 10.nnn.nnn.nnn IP addresses and it seems that several weeks ago they decided to "6to4" them, but unfortunately, with that move, SC got left behind limping...

  9. 13 minutes ago, Lking said:

     Based on what you cut/pasted from the report above, are you mixing results from the " Parsing header: " and " Finding links in message body "

    The " Resolves to " if from the body, and is from the header.  Each results in a report being send. and " I refuse to bother abuse@iana.org. " results in the devnull report, and the results in a report being sent to abuse{AT}hetzner.de

    Or do I not understand what you think is wrong?

    unfortunately, that is exactly what SC does at the moment with gmail's first (topmost) IPv6 (actually 6to4) private address Received: line:

    Received: by 2002:a9f:3d14:0:0:0:0:0 with SMTP id l20-v6csp1947284uai;
            Sun, 27 May 2018 17:19:06 -0700 (PDT)

    This IPv6 address is the 6to4 equivalent to which is a private network address.

    The next Received: line :

    Received: from gambashoping.com (static. [])
            by mx.google.com with ESMTP id m1-v6si28198295plt.276.2018.
            for <x>;
            Sun, 27 May 2018 17:19:06 -0700 (PDT)

    shows the actual spammer IP address []. This is coincidentally also the IP address that the link in the body of the message returns.

    SpamCop chokes on Gmail's "private" IPv6 address, and the rest of the Received: lines suffer from it and the real spamming IP does not get reported.

    Long discussions, explanations and workarounds are listed in the following two threads:




  10. 13 minutes ago, SpamStoolie said:

    I now have a scri_pt which modifies the headers like so:


    Delivered-To: x
    Comments: The following Received: header has been modified.
    Comments: SpamCop chokes on the 6to4 [RFC-3964] address (now parenthesized.)
    Comments: The equivalent IPv4 address has been inserted.
    Received: by (2002:a02:2109:0:0:0:0:0) with SMTP id e9-v6csp39361jaa;
            Thu, 24 May 2018 20:09:34 -0700 (PDT)


    It appears to work. I may rewrite it to be cross-platform.

    I like the Comments: section. if it's ok with you I'll blatantly steal it ;)

    I did something similar, but when I tried it with the parens, SC did a weird thing:

    Received:  by (2002:ab0:848:0:0:0:0:0) with SMTP id b8-v6csp1225199uaf; Sat, 26 May 2018 19:22:05 -0700 (PDT)

    Masking IP-based 'by' clause.

    Received:  by with SMTP id b8-v6csp1225199uaf; Sat, 26 May 2018 19:22:05 -0700 (PDT)
    I've never seen that before...

  11. Since I'm using gmail, I wrote a little apps scri_pt (I am still trying to implement a few additions to it) and like RJVB, my scri_pt (de)munges the 6to4 address and replaces the the IPv6 with its IPv4 address equivalent and IMHO I do believe this is an acceptable form of header (de)munging.

    Today I received a spam with an actual IPv6 address, and after (de)munging google's private 2002:axx:: address, SpamCop correctly identified the IPv6 sender, so I can attest, that SpamCop works when it comes to "valid" IPv6 addresses


    with "valid" I mean registered IPv6 addresses. I have yet to come by a 6to4 address from a registered IPv4 address to confirm the 2002:: working range when it comes to registered non-IPv6 addresses in the aforementioned 6to4 range.

  12. 3 hours ago, nzeid said:

    This is a pretty aggressive problem that almost obsoletes SpamCop, and I'm not sure what to make of this particular response.

    From what I understand reading so far, this header field is broken because the By-domain that Google is injecting is internal crap. But I'm actually impressed this is allowed at all... doesn't the Received field require a "from" section to begin with? If SpamCop already made the leap to handle such non-standard fields, why stop now? It's a small, innocuous change to the parser to simply skip a well-formatted field with consistent (bad) data. And if this kind of header mangling does in fact compromise the entire spam reporting process, why not take this opportunity to voice the dilemma in detail? We're all left scratching our heads wondering how this approach will encourage people to use SpamCop to report spam.

    If you're not the right person to talk to, to whom can we refer this problem?

    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.


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

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

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

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


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


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

  17. 4 hours ago, petzl said:

    Gmail are getting too smart for their own good! They are stamping their version of ARC rubbish above the real headers! which start at

    ARC-Authentication-Results: i=1; mx.google.com;

    Just copy and past into submission include that line SpamCop parses fine . Put what you cut out in notes

    Therein lies the problem :(

    I get about 20-30 spam/hour depending on the weather (well, not really on the weather, but it sure seems like it) so I wrote a little apps-scri_pt that pulls all my spam every hour and submits them as attachments to SC for reporting.

    To manually cut out the topmost Received: line (the SC parser works fine for me if I leave the rest of the ARC lines in the header) takes too much time, and to then re-insert it in the notes section, even more... I am absolutely sure, that if someone in the  development division pays attention to these latest IPv6 developments, and appends some corrective lines to the parser, SpamCop would again outshine the spammers with its glory.

    As you can see, it's not really an option for me. I could remove the topmost Received: line in the scri_pt, but that would again defeat the purpose as now I would be "spoofing" the headers of my submissions..

    Google is not spoofing anything. ARC is, in my humble opinion, a pretty nice development, albeit not foolproof if there is a fake mail server in the chain... ?

    the topmost Received: line (not spoofed, but since google seems to have moved their mail servers into IPv6 spaces, filled with the IPv6 address of the local server) is the only one that SC seems to choke on since it's a private IPv6 network and SC does not seem to parse private IPv6 addresses the same way as private IPv4 addresses.

    As I have already mentioned before, it would be nice if SpamCop would or could update their codebase to cover these "new" developments in the IPv6 addressing space.

  18. Hello, as of lately, every single spam message I get contains the line:

    Received: by 2002:ab0:848:0:0:0:0:0 with SMTP id some-id-code;

    This, as mentioned before in this and other forum threads is the IPv6 2002:a00/24 equivalent of a IPv4 network (private network)
    A non-spam email contains the line:

    Received: by 2002:ab0:848:0:0:0:0:0 with SMTP id some-other-id-code;

    These are the Google (gmail) internal IPv6 mail servers.
    Spamcop logically and understandably responds by saying "I refuse to bother IANA"

    The problem is, that if the header contained the non-IPv6 google internal mail server line:

    Received: by with SMTP id some-id-code

    the spam message is parsed correctly and the spammer IP received line pulled and reported and the spoofed received lines also detected correctly as spoofed lines.

    Today, it seems that no spammer has to worry to get their proxies pulled since SpamCop cannot parse the IPv6 private addresses like it does with the IPv4 Private addresses.

    It would be really nice if someone at the Cisco SpamCop division could look into this and fix it. I'm sure at Cisco they have knowledgeable developers who understand the IPv6 address space and email headers, and can fix the current SpamCop code to work with IPv6 to work along IPv4. Otherwise: Hello, Julian, sorry for bothering you, but could you add a line or two of code to fix this for us please?

    IPv6 example:


    Received:  by 2002:ab0:848:0:0:0:0:0 with SMTP id b8-v6csp616397uaf; Sun, 13 May 2018 06:31:21 -0700 (PDT)
    no from
    host 2002:ab0:848:0:0:0:0:0 (getting name) no name
    Possible spammer: 2002:ab0:848:0:0:0:0:0
    Received line accepted
    Received:  from cy105.mta.exacttarget.com (cy105.mta.exacttarget.com. []) by mx.google.com with ESMTPS id r185-v6si4924627ita.0.2018. for <x> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 May 2018 06:31:21 -0700 (PDT)
    host (getting name) = cy105.mta.exacttarget.com.
    cy105.mta.exacttarget.com is
    2002:ab0:848:0:0:0:0:0 not listed in cbl.abuseat.org
    2002:ab0:848:0:0:0:0:0 not listed in dnsbl.sorbs.net
    2002:ab0:848:0:0:0:0:0 is not an MX for mx.google.com
    Possible spammer: is not an MX for cy105.mta.exacttarget.com.
    Host cy105.mta.exacttarget.com. (checking ip) =
    Host mx.google.com (checking ip) IP not found ; mx.google.com discarded as fake.
    Display data:
    "whois" (Getting contact from whois.arin.net )

    Where does SpamCop even find that address in the header?

    SpamCop needs to update their code to work properly with IPv6. There is no way around it.