Jump to content

RobiBue

Membera
  • Content Count

    117
  • Joined

  • Last visited

Everything posted by RobiBue

  1. RobiBue

    SCv5 parsing

    I do wish as well, that parser changes could/would be posted, but that's up to Cisco/Talos to decide if a changelog or list of fixes wouldn't compromise their secrecy in security and vulnerability holes that they want to keep hidden from us mere mortals. That said/vented, see my latest post here:
  2. unfortunately M$'s IPv6 problem is different than Google's and wholly in M$'s court to fix it. See my reply here:
  3. Sorry it's taken me so long to reply, but I've been busy and could only do minimalistic replies, so I have waited until I had more time to delve in deeper... While the Gmail hack is no longer necessary, unfortunately Microsoft's outlook "hack" is still needed due to its difference... looking at the unmodified Received: headers in https://www.spamcop.net/sc?id=z6513483714z596b7c076a2121c3ce82e632cf6e31a3z [line] (Received origin/destination) [0001] Received: from PU1APC01HT007.eop-APC01.prod.protection.outlook.com (2603:10a6:800:92::20) [0002] by VI1PR06MB5360.eurprd06.prod.outlook.com [0003] Received: from PU1APC01FT052.eop-APC01.prod.protection.outlook.com (10.152.252.54) [0004] by PU1APC01HT007.eop-APC01.prod.protection.outlook.com (10.152.252.101) [0005] Received: from iainternalmeds.com (69.160.26.74) [0006] by PU1APC01FT052.mail.protection.outlook.com (10.152.253.137) (only the Received: lines are relevant here. Omitting the timestamps as well as the transfer method/protocol) Line [0002] is the host from which you picked the email up. Lines [0001] and [0004] should have the same host name and number, but only the host name is the same, so SC cannot safely confirm that it is the same host and with right determines the following: "Internal handoff or trivial forgery". Lines [0003] and [0006] also should have the same host name/address, but neither are equal, and therefore line [0005] is also a possible forgery. It looks complicated like this, but by keeping in mind, that the header lines are actually filled from the bottom up, let's "flip" the above Received: header lines: [line] (Received origin/destination) [0005] Received: from iainternalmeds.com (69.160.26.74) [0006] by PU1APC01FT052.mail.protection.outlook.com (10.152.253.137) [0003] Received: from PU1APC01FT052.eop-APC01.prod.protection.outlook.com (10.152.252.54) [0004] by PU1APC01HT007.eop-APC01.prod.protection.outlook.com (10.152.252.101) [0001] Received: from PU1APC01HT007.eop-APC01.prod.protection.outlook.com (2603:10a6:800:92::20) [0002] by VI1PR06MB5360.eurprd06.prod.outlook.com (only the Received: lines are relevant here. Omitting the timestamps as well as the transfer method/protocol) [0005] sent it [0006] received it which then in turn sent it as [0003] (PU1APC01FT052 is the same, but then the sub-domain name differs as well as the private IP address) [0004] received it which then in turn sent it as [0001] (here all: host, sub-domain, and domain are exactly the same, but unfortunately the address is not) [0002] received it in the end, waiting for you to pick it up. Therefore, unfortunately, Received: line [0001]/[0002] is the only trusted Received header: and the rest: [0003]/[0004], and [0005]/[0006] are possible forgeries in the eye of SC. By removing the top Received: line (here [0001]/[0002]) in outlook recipients, SC treats the following Received lines as Private/internal handoffs and correctly identifies the culprit in [0005]. This is not SC's fault, and SC cannot fix it. This fix has to come from M$ themselves, and, although SC did fix it in Gmail's sector, which, though Gmail's fault, and rightly also in Gmail's mail-server's code to be fixed, as 6to4 addresses should not propagate with private networks, is in the end a needed fix in SC's parser, and hopefully, whoever fixed it, made sure that only private networks are affected in the 2002:: 6to4 range, because it is possible (and allowed) to have valid IPv4 networks translated and propagated in IPv6 6to4 addresses. (please forgive the long-winding-ultra-long-complex-sentence. I hope it is understandable 🙃.) So in the end, the answer is as follows: For Gmail users: you do not have to remove/replace the 1st (topmost) Received: header. For Outlook users: you still have to remove/replace the 1st (topmost) Received: header. Sorry. This should answer both parts of the question. HTH
  4. unfortunately nothing to do with V5 https://www.spamcop.net/sc?action=showroute;ip=45.112.20.164;typecodes=16
  5. RobiBue

    leaseweb spam

    Thanks for checking, alas, the reason for the "correct" reporting address is: https://www.spamcop.net/sc?action=showroute;ip=209.58.179.237;typecodes=16 1/15/2019, 3:16:28 PM -0600 [Note added by x-x-x] Route added without comment not the new SC version
  6. RobiBue

    leaseweb spam

    for a while now I have been getting some spam from one or more leaseweb customers ([209.58.179.227], [209.58.179.237], and [209.58.179.238].) unfortunately, there are (at least) two problems here: the IP addresses involved are listed with ARIN pointing to " search-apnic-not-arin@apnic.net " and I simply do not understand why SpamCop cannot understand the transfer mechanism and search for the abuse address within APNIC. even if it would look up APNIC, leaseweb would probably end up being /dev/nulled... (see [5.79.74.138] ) anyway, manually reporting (with my anti-spammer email address) I have, after about 5 spams and 6 back and forth messaging their abuse desk (in Singapore -- I believe), managed the following 🤩
  7. Well, after several months of complaining and work-arounds, the SC update to v 5.0.0 finally did it (at least one part of this post's problem): IPv6 6to4 WORKS!!! 🤩
  8. and six hours after my post: Drum Roll 🥁 SpamCop v 5.0.0 © 2019 Cisco Systems, Inc. All rights reserved. and better: Gmail's fess-up with IPv6 6to4 WORKS!!!! 🤩 no release notes (yet) but at least some good news !!!
  9. it might have been, because: drum roll please.... tadaaaa.... SpamCop v 5.0.0 © 2019 Cisco Systems, Inc. All rights reserved. Here is your TRACKING URL - it may be saved for future reference: https://www.spamcop.net/sc?id=z6513281086z5dbadb8092da4e5415ec84737bfedba2z and the gmail IPv6 6to4 WORKS 🤩 Thank you Cisco! (took a while, but you finally figured it out without compromising the system 😉 )
  10. I don't think the update happened: I get: SpamCop v 4.9.0 © 2019 Cisco Systems, Inc. All rights reserved. and the gmail IPv6 6to4 address is still breaking the parser (although I don't know if they'll ever fix it...)
  11. RobiBue

    Any point in reporting spam from AMAZONAWS?

    I started doing that too for every amazonAWS spam. I am not sure how effective they are, as their case numbers keep changing for every report and every other reply. reporting to them gives me a case number, but when they reply about the action (which they can't tell me) they have yet another case number, and when I submit the same IP address a few days later (from a new spam) they give me yet another case number, so in this sense, I have no idea how they can even track their own cases... although I have been able to get a live person answer there... so they do read the stuff they get...
  12. RobiBue

    spam reporting question

    Sorry about that, I just copied the link without testing it "stand-alone" it was supposed to be https://www.cert-in.org.in, and then clicking on the link in the left menu [* Incident Reporting] (which ends up being that .jsp link that seems to go nowhere without context...) Confirmation of Spammer's Rules Rule #3: Spammers are stupid, and Spinosa's Corollary: Spammers assume everybody is more stupid than themselves. well, all I can say now: it works, and if it works for you , then great 👍 mission accomplished!
  13. RobiBue

    spam reporting question

    btw, if you click on [past reports] tab/button/link, you can find past TRACKING URLs by clicking on the number link provided for the report, and then on the [parse] link in the resulting screen. just for future reference
  14. RobiBue

    spam reporting question

    same as garbage can (a.k.a. /dev/nul) adding a report to incident@cert-in.org.in is described in https://www.cert-in.org.in/SecurityIncident.jsp from https://dnslytics.com/ip/103.111.41.221, I would add a report to the ASN abuse found through https://dnslytics.com/bgp/as132779 as well... that is, a report also to 'admin@rackbank.com' at least for the spam just provided in https://www.spamcop.net/sc?id=z6512015168z11faf14ef668f295d00a184d7761a5a0z
  15. RobiBue

    spam reporting question

    Hi ArtmakersWorlds, I suppose you are talking about the IPv6 address in the email header's "Received:" line beginning with "2002:", otherwise it would be helpful if you could post the "TRACKING URL" you received when submitting the spam to better understand what you mean. i.e. the URL you receive when reporting the spam (my link depicted in indigo purple) If it's the IPv6 (6to4) address, then see the threads here and here about the reasons why some of it isn't working and what Google is or isn't doing about it... HTH
  16. I believe that is the upstream "himself"... (couldn't find an upstream but APNIC themselves)... it's probably time to report to APNIC that the reporting email address is invalid... that pradeep guy has a huge IPv6 block ... he's probably admin[at]robosapi.com anyway
  17. Parswn67 probably meant to "re-post" Farelf's post from 2013 but something must have gone wrong, so here's the link as a reminder ;)
  18. I would like to propose a change in SpamCop's handling of cloudflare links. 1. when looking up the whois for the domain, or test the link, do not use the full path, only use the domain name, as a visitor trigger trap causes more spam to be sent as soon as the report is performed. I munged for that purpose every link in my "cloudflare" spams: https://www.spamcop.net/sc?id=z6493410150za18869ba12b686fd60a88c35e34dc44ez https://www.spamcop.net/sc?id=z6493410187zb583dc5e2b40660c7a81ed43e718e3aaz https://www.spamcop.net/sc?id=z6493340629z49245d803153055044b14f0dc24f00a3z https://www.spamcop.net/sc?id=z6493340613z69f628f405e36a4d6fbdf4e2014ffe58z and so on and so forth. it would be grand if SpamCop could do this automagically.
  19. RobiBue

    leaseweb spam

    <sfx mode="whisper, crowd"> YAY!!! </sfx>
  20. Abuse contact for '185.207.36.0 - 185.207.36.255' is 'info[at]fiberserver.net.tr'
  21. RobiBue

    leaseweb spam

    on 12/01/2018: http://forum.spamcop.net/topic/31073-abuse-contact-for-209581840-20958191255 and http://forum.spamcop.net/topic/31072-abuse-contact-for-209581760-20958183255 https://www.spamcop.net/sc?id=z6505161826z64add7cea35b443dd4f168a08a7582b8z even refreshing seems not to work. As I said, I wish SC would be able to get the abuse address from the correct registry... which in this case is APNIC, not ARIN...
  22. in your case, I'd be sending a manual report to sendgrid, and one to the IP owner of the link in the body. but the reports wouldn't be sent from the email account I received the message to, but from a spam reporting email address not associated with me. (I made one up a long time ago combating a Nigerian spammer with a name from another Nigerian spammer and have been using that one for manual reports ever since, always munging my name and other identifying strings explaining to the abuse desk the reasons for it.)
  23. mine reports without problems: https://www.spamcop.net/sc?id=z6504258765z2c686bd18ea5c5a2c21ec63c840b3fbbz if you could provide the tracking URL (like the one I provided above) it would be easier to see the problem. I used the lines you provided for a test, and it parses it correctly... (removed spaced lines from headers and added X- to Received: line. See comment in parse of test link). I must admit, I do not use the Mailhost configuration. I report manually/submit via email attachments, so that might be your issue...
  24. @MIG, he actually does that. It just takes a while (at least for me, since I rise earlier due to time zone location...) And he does a great job at it Chapeau! Thanks LKing! Namaskaram! 🙏
  25. Abuse contact for '209.58.184.0 - 209.58.191.255' is 'abuse[at]sg.leaseweb.com' Information related to '209.58.184.0/22' -> AS133752
×