Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by RobiBue

  1. well, I believe I found my spammer(s)... probably the same scumbag unless they teamed up... List of domain names registered by Michael Wallace https://domainbigdata.com/nj/PMs8PeMWLXMFAfjPwmyV3g List of domain names registered by Frank Marsicano https://domainbigdata.com/nj/2NMIE802bt4WH2rc3SoTUA List of domain names registered by Chris Patterson https://domainbigdata.com/nj/rnPab-DpPIdNUYynMibFFw List of domain names registered by Richard Hawking https://domainbigdata.com/nj/GlBwSDCvDWjzlWpRAgo9Kg List of domain names registered by Anton Lassen https://domainbigdata.com/nj/vubKHIY--XkSbXo_sFyHPw some reports with the 58.14/16 range: https://www.spamcop.net/sc?id=z6471482675z858c71a05814a9763517674009c94768z https://www.spamcop.net/sc?id=z6471482674z9ab0a9c820151d7ac9ce9a041686d4c6z https://www.spamcop.net/sc?id=z6471482673zcd19939939e9d574cdb141b1b360f152z https://www.spamcop.net/sc?id=z6471482672z08f29a0817817fdf745140d9fa2031baz https://www.spamcop.net/sc?id=z6471482671z9f4ead4df33727978572d5e46ac87ad1z (and there are over 3000 more of these) and the new 27.146/16 spams: https://www.spamcop.net/sc?id=z6471634192z1d8fd5aece82eb5feb80e4b6b19f6eb3z https://www.spamcop.net/sc?id=z6471634194z7350adbd7dbeaedf80def1cb4631741dz https://www.spamcop.net/sc?id=z6471634195zf18a0c1292ecbd3adb3a2a03e64e3fb6z https://www.spamcop.net/sc?id=z6471634196zdc9be4ffc73a9c61325ef1a168149c9bz https://www.spamcop.net/sc?id=z6471634197z3f7ef41d7685eb94ae14eaf91f4ef100z This isn't a DoS attack, it is just a spammer at work hopping through ISPs that want to make a quick buck...
  2. RobiBue

    The parser finds no links

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

    The parser finds no links

    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. Abuse contact for '' ([]) is ' info[at]abstation.net' RIPE db Responsible organisation: ahbr company limited Abuse contact info: info[at]abstation.net Other contacts: abuse[at]abstation.net, rumi[at]abstation.net
  5. I believe that Paerhc is actually subscribed to that blogspot site; iow he wants the information coming from there. At least that's how I understand it... The problem is, that apparently some spammers are using that blogspot as delivery engine. The only ones that can prevent that, are the blogspot owners/admins.
  6. RobiBue

    Reporting Issue's reason Fake Headers

    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: <quote> 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. </quote>
  7. 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. HTH
  8. 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) https://whois.arin.net/rest/net/NET-23-111-128-0-1/pft?s= has two abuse addresses: abuse@noc4hosts.com, and abuse@hivelocity.net
  9. RobiBue

    Spamcop cannot find source IP

    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)
  10. RobiBue

    Constant reporting problems

    @ 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...
  11. RobiBue

    Constant reporting problems

    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: 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/
  12. RobiBue

    Spamcop cannot find source IP

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

    Spamcop cannot find source IP

    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.
  14. 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 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.
  15. ...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.
  16. 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.
  17. 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
  18. 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. 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...
  19. 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.
  20. 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
  21. 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: 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. []) 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.