Jump to content

RobiBue

Members
  • Content count

    58
  • Joined

  • Last visited

Community Reputation

0 Neutral

About RobiBue

  • Rank
    Member

Recent Profile Visitors

165 profile views
  1. 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.
  2. 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...
  3. 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
  4. 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)
  5. when I read the SBL listing, I noticed that it has been listed since 2015: Ref: SBL247801 167.103.0.0/16 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".
  6. 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...
  7. 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=167.103.35.178 (the [refresh/show] link) for 167.103.nnn.nnn https://www.spamcop.net/sc?action=showcmd;cmd=whois 167.103.35.178%40whois.arin.net https://www.spamcop.net/sc?action=showroute;ip=167.103.35.178;typecodes=17: Reports routes for 167.103.35.178: routeid: 77437349 167.103.0.0 - 167.103.255.255 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 167.103.0.0/16 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.
  8. 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...
  9. 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
  10. 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...
  11. 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.
  12. I want to expand on my theory about the mis-configured server... Ok, the topmost (last) Received header Received: from st11p00im-smtpin002.mac.com ([17.172.80.20]) by ms55025.mac.com (Oracle Communications Messaging Server 8.0.1.3.20170906 64bit (built Sep 6 2017)) with ESMTP id <0PD000KG3DK8YJD0@ms55025.mac.com> for x; Sun, 05 Aug 2018 22:09:44 +0000 (GMT) The mail server "ms55025.mac.com" receives the message from server "st11p00im-smtpin002.mac.com" and identifies the IP address [17.172.80.20] which in turn was received in the previous Received header (below) by server "st11p00im-smtpin002.me.com" (notice the coincidental same name, but me.com instead of mac.com domain -- both apple domains nonetheless) from the Russian server "kknd1.ru" and identified to be IP address [84.22.137.8] (rDNS identifies the address as kknd1.ru) Received: from kknd1.ru (kknd1.ru [84.22.137.8]) by st11p00im-smtpin002.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTP id <0PD0005G5DK5U970@st11p00im-smtpin002.me.com> for x (ORCPT x); Sun, 05 Aug 2018 Of course, sadly enough, at the moment, if I ping either me or mac servers, I get nil... but the Russian server is there...
  13. I actually believe, Apple should look into the configuration of their SMTP server named st11p00im-smtpin002. When it receives the email, it places the host name st11p00im-smtpin002.me.com into the Received: header as "received by", then, when it sends the message on its merry way, the same server is now known as st11p00im-smtpin002.mac.com. me.com is an apple domain, just like the mac.com is. My take is, that some admin forgot to change the domain name on the server... If I were you, I'd get in touch with Apple. They'd more than likely be willing to fix their server mis-configuration...
  14. Ok, that's not it, but then again, it is... apparently Google's internal mailing is creating havoc. As you can see, the bottom-most (aka first) Received: header is Received: by 2002:a17:90a:3aac:0:0:0:0 with HTTP; Thu, 2 Aug 2018 07:36:54 -0700 (PDT) There is no from in the received line. The by is one of those private networks from IPv4 in 6to4 format, which SpamCop correctly identifies as 10.23.9.10 but, as I mentioned earlier, since it's a 6to4 address, it can't cope. and no, you won't be able to send a report for this one via SpamCop. This one needs "manual" intervention... https://www.google.com/contact/ Sorry.
  15. Well, I guess it wouldn't (or couldn't) hurt if SpamCop users/reporters with gmail accounts send their feedback... I found the feedback link in gmail by clicking on the settings gear in the "new" gmail (or classic/standard view). Can't find it in the basic HTML view though.
×