Jump to content

RobiBue

Membera
  • Content Count

    243
  • Joined

  • Last visited

Posts posted by RobiBue


  1. 26 minutes ago, lepa71 said:

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

    Here is another one.

    https://www.spamcop.net/sc?id=z6466849060zdcafb4e78746831a976de90fabffbf97z

    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 [10.159.61.20] (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...


  2. 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 95.216.150.71 " if from the body, and 10.159.61.20 is from the header.  Each results in a report being send.  10.159.61.20 and " I refuse to bother abuse@iana.org. " results in the devnull report, and the 95.216.150.70 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 10.159.61.20 which is a private network address.

    The next Received: line :

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

    shows the actual spammer IP address [95.216.150.71]. 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:

    http://forum.spamcop.net/topic/25123-address-2002adfaa9100000-gmail-not-associated-with-any-of-your-mailhosts/

    http://forum.spamcop.net/topic/23516-spamcop-cannot-find-source-ip/

     


  3. 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 10.2.33.9 (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 10.176.8.72 (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 10.176.8.72 with SMTP id b8-v6csp1225199uaf; Sat, 26 May 2018 19:22:05 -0700 (PDT)
     
    I've never seen that before...

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

    https://www.spamcop.net/sc?id=z6466615389z4cdd3ad918544a33bcf0dc613af17294z

    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.


  5. 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 10.0.0.0/8. 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.

     


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


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


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

     


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


  10. 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
    https://www.spamcop.net/sc?id=z6465051289zf879ca5b6e1b837b8e57756639b0bdc2z

    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.


  11. 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 10.0.0.0/8 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 10.236.180.19 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:

    https://www.spamcop.net/sc?id=z6464737137z474ae3b9e88802b0d23dff1750a16192z

    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. [136.147.181.105]) by mx.google.com with ESMTPS id r185-v6si4924627ita.0.2018.05.13.06.31.21 for <x> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 May 2018 06:31:21 -0700 (PDT)
    host 136.147.181.105 (getting name) = cy105.mta.exacttarget.com.
    cy105.mta.exacttarget.com is 136.147.181.105
    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: 136.147.181.105
    136.147.181.105 is not an MX for cy105.mta.exacttarget.com.
    Host cy105.mta.exacttarget.com. (checking ip) = 136.147.181.105
    Host mx.google.com (checking ip) IP not found ; mx.google.com discarded as fake.
    Display data:
    "whois 10.176.8.72@whois.arin.net" (Getting contact from whois.arin.net )

    Where does SpamCop even find that 10.176.8.72 address in the header?

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

     

×