Jump to content

RobiBue

Members
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About RobiBue

  • Rank
    Newbie
  1. RobiBue

    Spamcop cannot find source IP

    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.
  2. ...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.
  3. 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.
  4. 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
  5. 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...
  6. 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.
  7. RobiBue

    tinyurl parsing

    I do second that (a year later) with an addition to test the get headers of links for 302 redirects and report the whole redirection chain to their respective ISPs/abuse desks
  8. 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.
×