Jump to content

RobiBue

Members
  • Content Count

    59
  • Joined

  • Last visited

Everything posted by RobiBue

  1. 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.
  2. 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.
  3. 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...
  4. 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
  5. 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)
  6. 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".
  7. 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"
  8. 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...
  9. 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.
  10. 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...
  11. 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
  12. 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...
  13. 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.
  14. 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...
  15. 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...
  16. 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.
  17. 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.
  18. With Gmail, SpamCop has been having problems lately, because their mail system adds their internal IP addresses for their mail hosts as so called "6to4" addresses in IPv6 form, and that breaks SpamCop. SpamCop has no wish to check if the IPv6 address would be a private address (10/8) and handle it as a private address. Google is misusing the 6to4 format not conforming to RFC 3056 section 2 and reporting their private mail host as IPv6 in the 6to4 format. Google needs to fix that, but regardless, SpamCop needs to be able to cope with it and sadly it doesn't. If the topmost Received: header starts with 2002:axx:xxxx:0:0:0:0:0:0 then manually parenthesize that address and place mx.google.com in front: Received: by mx.google.com (2002:axx:xxxx:0:0:0:0:0:0) ............ and it should work... that is, if that is your problem, but without the TRACKING URL it's hard to diagnose the problem ...
  19. I received this from SpamCop: <quote> Google has promised to fix the issue but have not provided an ETA of a fix. We [SpamCop] 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>
  20. Ok, just reread the thread and found the following Yeah, Gmail adds their Received: header with a 6to4 IPv6 address from a private 10.0.0.0/8 network which according to RFC 3056 §2 is not allowed, but them being google, do it anyway regardless of the consequences. This, in my opinion, is something that google shouldn’t have implemented and should fix. SpamCop should be able to cope with the 6to4 address and see it as an internal private address just as it would be if it was given the original 10.nnn.nnn.nnn address. Currently it seems that neither SC nor google is about to budge. All we can do, is either delete the 2nd line Received: header with its faulty IPv6 address and paste it as a comment for the receiving abuse recipients for completeness, or put the IPv6 address in parentheses and place its equivalent IPv4 address in front. an example of that 2nd line: Received: by 10.176.75.22 (2002:ab0:4b16:0:0:0:0:0) with SMTP id h22-v6csp5358367uaf; Tue, 31 Jul 2018 11:25:32 -0700 (PDT)
  21. does your spam by any chance arrive to a gmail account? (or is delivered by gmail)
  22. RobiBue

    Reporting Issue's reason Fake Headers

    it's not the ARC headers, it's the Received: header containing the IPv6 address in 6to4 form which points to a private IPv4 address [rfc 1918] and no, the Received header with that type of IPv6 address (private IPv4 in 6to4 form) is not allowed, therefore not legit. [rfc 3056] section 2:
  23. RobiBue

    Reporting Issue's reason Fake Headers

    Yeah, and according to an email I received from SC they won’t do anything because they seem to think they might open a security hole if they do that... btw, could you point me with a link to the gmail forum you mention?
  24. As is the to: header... I believe the “munging” of the List-Unsubscribe: header is a side effect of a regex command which is misinterpreting the missing space after the colon as part of hiding a “valid” email address... I believe Cisco/talos need to look into that, as it breaks the parser.
  25. I see the problem that you're having. It isn't what I thought, but nonetheless bad. The problem is, that the sender's mailing program does not add a space right after the colon (:) ending the header type. All the messages I have seen have that extra space after the colon. It is not required by RFC standards, but it seems to hurt SC. I tried your message, and if you insert that space after the colon, it works. https://www.spamcop.net/sc?id=z6475844094zd9d6160d20740d76a1fb1f9ae1dbcbb8z (I added a space after every one that didn't have one, but I believe that if you only do it with the List-Unsubscribe: header, it should work too.
×