Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by RobiBue

  1. careful, the above post could be a password phishing link... I haven't looked into it, but it looks suspicious... https://www.spamcop.net/sc?track=http%3A%2F%2Fwww.aoltechsupportnumber.com @admins, my post can be deleted if you delete the above post or if the link is safe
  2. if that's the case, then just post the header and the first few lines of the body in their form with the comment that the rest was truncated or omitted due to size restrictions. I do that when I report spam larger than 50kiB
  3. if they are that large, it would almost seem that they would contain some malware... (a virus or such)
  4. from the vast amount of data breaches, this goon got my old password as well: https://www.spamcop.net/sc?id=z6495594649zd2d6f1f75886a3a021dda5474e8bf174z reported. his mo seems to be that he subscribes you to some prn sites and then sends the canned letter...
  5. lately, I have to manually alter every cloudflare spammer link. I noticed a few weeks ago, that whenever I reporte cloudflare spam (I call it cloudflare spam because the links are hosted by cloudflare, and the spammer spoofs an inactive IP range -- currently CCAMATIL ( 167.103.249.nnn ) -- and seems to be getting away with it) a few seconds later, fresh spam from, you guessed it, cloudflare fills my inbox. So, whenever SpamCop analyzes the links (just touches them), the spam gets triggered. Now I munge the ID number and alter it verbally as: e.g. http://airlinedo.com/?--ID-number-5-(munged) where the 5 in this example is the last of 13 digits https://www.spamcop.net/sc?id=z6493410150za18869ba12b686fd60a88c35e34dc44ez or http://checkshownontv.com/?--ID-number-8-(munged) in this case it's 8 ... https://www.spamcop.net/sc?id=z6493410187zb583dc5e2b40660c7a81ed43e718e3aaz it would be nice if SC could refrain from using the full path so that the visitor trap doesn't get triggered And yeah, the originating IP address is also a problem as there is no real owner for the range, even though indirectly it belongs to the Australian branch (Amatil) of Coca-Cola. APNIC told me that someone is spoofing those IP ranges.
  6. Hello Alexey, this is a user supported forum, but we'll try to help as well as we can. it seems that your system doesn't have "double opt-in". this means, that when the user subscribes, you send a short message to the email address provided asking the subscriber to confirm (preferably not via email but via web-link or to enter a code sent) that they want the subscription to your list. if they do not react within a certain amount of time, you discard the address and leave it at that. do not keep on asking for confirmation, as that constitutes spamming too. also, if the user changes the email address, you do the same, send a message to the new address asking for confirmation via link or by entering a code. this way, you can make sure that someone who is trying to frame you, can not succeed. also, keep a log of the subscription requests and the messages where the replies come from (IP addresses) there could be a possibility that someone is adding "innocent" email addresses to your list, and with this method you can make sure that you're not getting in trouble. personally, if I receive unwanted mail (spam, ube, uce) I do not click on links. I report it. if the spammer keeps sending me requests to confirm my subscription, they are spamming me. if they sent the request once, and don't send me any more requests, then they can easily explain to their provider the way their system works, and if someone is trying to get you in trouble, you can follow up on recent attempts to subscribe (if the same IP address appears to be subscribing many email addresses, you can explain to your provider the situation and even block the IP address attempting to subscribe... you might have to clean out your address DB now, since you don't know who of the 5000 is the one that didn't want to be subscribed. hope this helps
  7. RobiBue


    The is not an IP address! It is the version number of the “IceWarp” system used by mail.gvii.net. SpamCop thinks that it’s an IP address because it is commented (in parentheses) after the host name... unfortunate misatribution...
  8. as i mentioned, it's M$'s (microsoft's) fault because they break the chain. I do agree, that it is pointless to report your own email provider instead of the source, but there's nothing we mere "customers/end-users" can do if the big wigs don't want to play along.
  9. Hi Klappa, I can try to explain what’s happening here: In the topmost (last) Received: line Received: from CO1NAM04HT207.eop-NAM04.prod.protection.outlook.com (2603:10a6:4:2b::32) by DB4PR03MB524.eurprd03.prod.outlook.com with HTTPS via DB6PR0801CA0064.EURPRD08.PROD.OUTLOOK.COM; Tue, 2 Oct 2018 00:49:39 +0000 notice the address 2603:10a6:4:2b::32 which is a valid assigned IPv6 address belonging to M$. The next Received: line Received: from CO1NAM04FT010.eop-NAM04.prod.protection.outlook.com ( by CO1NAM04HT207.eop-NAM04.prod.protection.outlook.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1185.13; Tue, 2 Oct 2018 00:49:37 +0000 appears to come from IP address, which is a private network address, so it is not trusted. The following (preceding) Received: line Received: from sfac11.wysweb.com.au ( by CO1NAM04FT010.mail.protection.outlook.com ( with Microsoft SMTP Server id 15.20.1185.13 via Frontend Transport; Tue, 2 Oct 2018 00:49:36 +0000 which actually contains the spamming IP address could already have been forged by the untrusted host mentioned above. The problem is that M$/Hotmail/Outlook breaks the chain causing SpamCop to report the wrong address. This is not SpamCop‘s fault, but M$’s.
  10. RobiBue

    ocn.ad.jp spam

    Well, I still have my hotmail address and it works just fine. but I agree, since M$ moved the hotmail accounts to outlook, they most likely got rid of those addresses, so if SpamCop redirects automatically to them, it should raise an eyebrow or two...
  11. But again, according to ARIN: https://whois.arin.net/rest/net/NET-209-200-0-0-1/pft?s= their abuse address is abuse@webair.com
  12. RobiBue

    ocn.ad.jp spam

    It would be so much easier if instead of a screenshot, only the URL would be provided... https://www.spamcop.net/sc?id=z6488956777z48d6c277dfcfacb57994880635860105z Anyway, it is clear why this and probably all hotmail emails are reported to Microsoft... the topmost Received: line contains the IP address 2603:10a6:4:8f::13 which is allocated to MSFT... now the next Received: line contains the following private network address: and this breaks the chain, therefore SC reports the message to the last valid provider: Microsoft. now why in Sam Hill isn’t it actually being reported to abuse@microsoft.com is probably because some “looong” time ago, abuse@outlook.com was the place to report to and SpamCop had a special “report desk” there... problem is, by breaking the chain, Microsoft alongside google et al. put SpamCop in a precarious position where spam isn’t being reported correctly anymore. The email system is broken and spammers are having a free pass fest. It’s not SpamCop’s fault, but SpamCop/Cisco is not taking the problem seriously either. Sad days in the anti-spam community.
  13. RobiBue

    ocn.ad.jp spam

    @Salfordian, I don't know about you, but I have no problems reporting spam through gmail. (although I rather use SpamCop) I'm with its8up, if we don't know what you're doing, we can't help you. Gmail has a quota of how many messages (emails) you can send per day, depending on how you send them. I reached that limit once, but haven't run into that problem anymore, and I've had this account since I got an invite to gmail on Nov, 2005 The only failures I get are the ones where the abuse mailbox is dead or the space for inflow on their side has run out. and then I nicely reach out to ARIN, RIPE ... or whoever handles their AS info and ask them to reach out to their registrant to fix their abuse contact. so far it (almost) always has worked for me.
  14. RobiBue

    Flooded With Groupon spam

    The problem with OP‘s issue is that google is using their 10.nnn.nnn.nnn private network addresses encapsulated into 6to4 IPv6 addresses and propagating them into the Received: headers. SpamCop chokes on that specific „internal“ network type IPv6 style. Instead of ignoring it like it does with IPv4 private network addresses, it wants to report to the address holder => IANA.ORG. Problem is, neither SpamCop nor google want to fix it.
  15. Unfortunately, no. there is no fix in sight. some of us are using workarounds (php, apps-scri_pt, ...) or other methods to replace the 6to4 IPv6 address with its IPv4 counterpart. Spamcop (Cisco) has no desire to fix it, since they claim it opens vulnerabilities (I say that it's already a vulnerability by not fixing it) and Google (et al.) has, AFAICR, mentioned to spamcop that they are looking into fixing it, but since other big emailers have followed suit into abusing the 6to4 IPv6 addressing with private IPv4 networks, there is a very slim chance that it will be fixed at all. It's sad, but it is what it is. And with that, I believe, Cisco is putting the nail in SpamCop's coffin...
  16. Hello Psy and welcome to SpamCop. There is a possibility that someone has subscribed a "third party" through your website, because someone thought he or she'd be interested in your real estate. Another possibility is that a competitor of yours has subscribed "innocents" and one or more of them are SpamCop users and don't like spam... I don't Unless you have double opt-in implemented, I don't think there is nothing you can do except stop sending out your emails and have whoever is interested opt in again. in other words, start from scratch. (you might want to send out an email stating that due to a system problem, the mailing list was corrupted and you have to rebuild it, asking interested parties to re-subscribe but using double opt-in) Just make sure it's double opt-in, i.e. require a confirmation email to confirm the subscription, but don't follow up if they don't confirm the subscription. Only one confirmation email. If they keep coming, I report them... If you have someone unsubscribe, don't send a confirmation email to confirm that they are unsubscribed. I hate those and I report them, since I already stated in my unsubscribe that I don't want any more emails. you also might want to log the IP address used to subscribe email addresses on the website, in case someone is trying to abuse your system to subscribe others. good luck
  17. RobiBue

    Reporting not working mainbody

    @oZoneCapHill: if I copy and past what you showed, with the hTTp:// intact, the message parses, but it doesn't look at any links. To me, that is ok, as many times links are "innocent bystanders"... The real problem though, is that the message can't follow the "Received:" trail and will accuse Hotmail for spamming, while the real culprit, in the above message, is aruba.it. If you remove the topmost Received: line and parse the message, you will notice the difference. it's that (2603:10b6:405:16::18) address that gets SpamCop (well, not really), but since none of the mail hosts are reachable and the MX for outlook.com domain is outlook-com.olc.protection.outlook.com and it's addresses rotate along the line of 104.47.n.33 and are not reachable either SC will say: 2603:10b6:405:16:0:0:0:18 is not an MX for BN7PR04MB4338.namprd04.prod.outlook.com 2603:10b6:405:16:0:0:0:18 is not an MX for SN1NAM04HT194.eop-NAM04.prod.protection.outlook.com 2603:10b6:405:16:0:0:0:18 is not an MX for BN7PR04MB4338.namprd04.prod.outlook.com and will think hotmail is the spammer... see the difference: with the first received line (report would go to hotmail.com) without the first received line (report would go to staff.aruba.it)
  18. when I read the SBL listing, I noticed that it has been listed since 2015: Ref: SBL247801 is listed on the Spamhaus Block List (SBL) 2015-02-18 21:50:49 GMT | APNIC The way I understand it, CCAMATIL used to have that range under ARIN's umbrella, or even under InterNIC's, but then ARIN transferred the range to APNIC, probably while CCAMATIL wasn't physically using it. I am also asking APNIC if there is a way to physically find out who is using those address ranges, and maybe APNIC could impose severe punishments to ISPs or Number Registrars who abuse or allow abuse for addresses in limbo or under "assignment".
  19. 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"
  20. Thank you Petzl, very informative! I passed the spamhaus.org info on to the cybersecurity guy at Coca-Cola, since they are in the process on getting those IP addresses back, they ought to know what is required to have the range cleared from the SBL... btw, what do you mean with the quote below the SBL link? I don't get the connection...
  21. Well, it seemed to have worked, because I suddenly stopped receiving spam from them (12.08/2018 20:00:00 PDT)! YAYY!!!! Victory!!! Alas, on the 28th I start getting the same garbage again, but now from a different IP address (although still in the Asia/Pacific area as the first 2) This time it's spewing from 167.103/16. Now here comes the hammer: the listing is named Coca-Cola Amatil, but the IP range was transferred from ARIN to APNIC. SpamCop demonstrates this in a weird way: https://www.spamcop.net/sc?id=z6482664977z1149d3dfe903230031db2f70e94df5b2z (TRACKING URL) https://www.spamcop.net/sc?action=rcache;ip= (the [refresh/show] link) for 167.103.nnn.nnn https://www.spamcop.net/sc?action=showcmd;cmd=whois https://www.spamcop.net/sc?action=showroute;ip=;typecodes=17: Reports routes for routeid: 77437349 - to: search-apnic-not-arin@apnic.net Administrator found from whois records and then, in the parse: I refuse to bother search-apnic-not-arin@apnic.net. Using search-apnic-not-arin#apnic.net@devnull.spamcop.net for statistical tracking. Using last resort contacts search-apnic-not-arin#apnic.net@devnull.spamcop.net SpamCop doesn't look for the APNIC side (which wouldn't matter much because the data is currently invalid either way) but there should be a way for spamcop to follow the trail here to APNIC too... ...but I digress... During that time, the IP range wasn't (and still isn't) under CCAMATIL's control, and some slimeball ISP is using this transfer period to the spammer's advantage. whoever this slimeball IPS and their pet spammer are, they are criminals and should be stopped. I would love to know how to see the real current CIDR holder for 167.103/16 and how these slimeballs can steal unused IP ranges. If anybody has any ideas, please let me know. I am currently in touch with Coca-Cola Amatil's Group Security Lead - Threat & Vulnerability Management. The Security Lead's reply to my inquiry: " I've taken an extensive look at our data lake and other log repositories. I also consulted with our networking & infrastructure team and we've arrived at the conclusion we aren't actually public using these address. There was a time when wasn't under our ownership (during the transition from ARIN to APNIC) and from what I've been made aware of it's currently in a "assignment" state with APNIC. It appears these actors have taken advantages of this and same how have gotten their ISP to allow them to use those addresses. Unfortunately I don't have an answer to how these actors have done this. " then he continues: "We are currently filing out an application with APNIC to take full ownership of these addresses. We will then see what we can do with the assistance of APNIC to contact the ISP to stop this from happening. In parallel once we have proper ownership we will update the notify address accordingly." He is going to keep me in the loop with further developments on their side.
  22. RobiBue

    Parsing Confusion, old n00b

    Hello Sbimos, what is the TRACKING URL you receive after you submit the spam? in might help to narrow down your problem... here is one of mine I just reported: SpamCop v 4.9.0 © 2018 Cisco Systems, Inc. All rights reserved. Here is your TRACKING URL - it may be saved for future reference: https://www.spamcop.net/sc?id=z6482545787z79ecd3552584f561649bc259a1cb6bf0z and the way I solve the problem with that issue...
  23. In this post I provided this link. all you do is place the IPv6 6to4 address in the box. et viola! an IPv4 address (if it is a 6to4 that is...) HTH
  24. RobiBue

    Is it an IPV6 issue again?

    yes, definitely IPv6 issue. I wish SpamCop would take initiative and patch that 6to4 private address hole, and I hope google will change their private addressing soon... Google shouldn't be using it like that anyway...
  25. Yes and no... SpamCop can only follow the trail of the received headers, and unfortunately Apple breaks that trail with their server announcing to be from domain me.com in the first header, but then being identified to be from Mac.com. So yes, SpamCop is misidentifying the offending domain... And no, SpamCop identifies Mac.com as the offending domain because Apple has broken the chain, and believes that kknd1.ru is a spoofed header.