Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by RobiBue

  1. 1 hour ago, petzl said:


    I concur. Sendgrid is a spammer friendly host and needs to be made aware that this is not acceptable. Thus:


    gives me parent: STEADFAST-6 (NET-50-31-0-0-1)

    which in turn returns Related organization's POC records.


    from which I can take (extrapolate?(sic))

    Abuse: ABUSE959-ARIN (ABUSE959-ARIN) -> https://whois.arin.net/rest/poc/ABUSE959-ARIN.html

    and you have the aforementioned abuse email address ;)


  2. G'day Chris,

    On 1/31/2019 at 8:38 PM, csouter said:

    If a message has been correctly identified as spam, normally I will still report it to SpamCop, (having first redacted those lines that Gmail inserts into the headers, causing SpamCop to think that there's "nothing to do").

    Redacting/removing those lines for gmail spam is not necessary anymore since the new SpamCop upgrade to version 5 :)

    You can save/skip that step entirely.

    Greetings to the other side of the world :) (it's cold up here ;) )

  3. 9 hours ago, Lking said:

    Of course it is possible to set the forum to require approval for all first post, spam or otherwise.  Admin would still need to look at each first/new post to process as spam or approve and/or respond.  The only difference would be members would not see spam and new members would have to wait until Admin approves their post before getting any help.  JMHO

    :( yeah, that's not what I meant though :( admins like you have already plenty on their plate, and I've noticed, there aren't many around... in fact, I've only seen two or maybe three admins around...

    what I meant was, to make it easier on y'all, have the system automatically sort newbies and forum spammers maybe through a learning curve, which would in the end benefit the users and the admins. Of course, such a system would have to be written and implemented and I'm not sure if one like that already exists -- although I would think so...

  4. back in May 2018 I started receiving a slew of spew which peaked in the hundreds in June-August, where I finally got the Gmail faux-pas with 6to4 IPv6 problem completely figured out and was able to report correctly to the necessary abuse desks. The spam started diminishing again and now, finally, with a few oddballs, the last one so far I received was on 4 days ago! YAY!

    Thanks for all that helped me figure out the IPv6 problem and that gave me tips and showed me tricks ;)

    I believe in the end it has been a combination of SpamCop and manual reporting where SC didn't find the correct abuse desk or couldn't follow the region's whois server ("refuse to bother lacnic" or "apnic") because the address is/was an old grandfathered transfer from "internic"...

    Anywho... 2 - 3 spams a week seems like a pretty good deal where it was over 100 a day...

    if now, the forum spam could be handled the same way and reduced to nil... wouldn't that be great... not a question, just a loud thought ;)

    I know, since SC deals with spam (duh) it would be pointless to implement a spam filter in the fora since many valid posts would be marked as spam (again duh) but there should be a way where newbies and forum spammers could be sorted out at the beginning, and have a few newbie posts get the warning that a forum admin will need to approve their post.

    I believe that could work, as it would burden the admins less since they wouldn't have to take care of every forum spam -- at least I believe so...

  5. On 1/25/2019 at 7:59 AM, stan55 said:

    I am getting this message very often.  I check the number of bytes in my word processor.  I never send anything more than 40K bytes.  Why does SpamCop complain very often about these message sources?  How do you count the number of characters anyway?  I suspect that if I sent one of 100 characters, you would also complain that it was too long, although you would have numerous other complaints.

    Also, there seems to be no problem when I submit the report.  Almost every time I login, there is a message for me that says I am submitting a report that is too large. Is it possible for your code writers to catch the real problem and report it as soon as I submit the wrongly formatted report?  Sometimes, I wonder if SpamCop is still actually operational at all. The coders don't really seem to have it all together.

    depending on the email program/UI you use, if you run into a >50k problem, you might want to try to export the spam as .eml or .txt (depending on the ability of your emailer) and check the size like that. You can then use a text program like notepad (if you use M$) and go down about half the way into the message and just delete the rest from there on down. then attach the truncated file to a new email and send it to your secret email code at spamcop.

    w/r to the login, that happens when you are not logged in and end up with a link to a previously reported spam

    I get that often and all I do is click on the report spam tab/link at the top of the page. that solves it.

  6. I wouldn't bother with the links in the spam body. Oftentimes they are just sites that spammers try to get in trouble.

    I know, in this case they are not, or most probably not, but many times, when they are connected to the spammer themselves, they contain a tracking link which links you (or better, your address) to the received spam, and every time the link gets a hit, it means for the spammer:

    a) they get paid
    b) they can send one or more spams to that email address

    The less (or zero) activity the spammer gets on the link, the more likely your address will get dropped from his list.

    And as you have already noticed, cloudflare doesn't care what or who they are hosting as long as they get paid

    so again, my suggestion here is either:
    a) don't report these kind of links
    b) don't even bother reporting this type of spam

    I know, the latter sounds counter intuitive, but taking into consideration that spamcop checks the link, that means that the spammer gets their activity and you'll get another swarm of spam delivered...

    Of course, you are welcome to do some manual work and edit those links by removing the tracking path completely (with the notice for the abuse desk that the link has been modified to protect yourself)

    here is a boilerplate I place in the spams I receive for that purpose:

    Comments: The recipient of the email wishes to stay anonymous and therefore
           has munged his name and/or address for privacy reasons to strings like "x-x-x" or "x".
           Please respect his privacy. 

    I was hoping SC version 5 would have the full links reduced to host/domain only and not the full path... pity

  7. 5 hours ago, MIG said:

    Hello Lking, thanks for replying:).

    I have submitted both modified & unmodified data, end result, different, hence my question.

    I've asked this question on other's posts, provided examples, no-one responded, hence this post - leading me to cogitate, which method is more accurate, more likely to produce the best outcome, i.e, get notifications sent to those responsible that will really pay attention & take action?

    No modified source data, i.e 1st {Received) not removed: 


    Modified source data, i.e 1st {Received) removed:


    & a v5 general ?, do you know if there's any available v5 information/changes faq available please? If so where? Please!:)

    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:


  8. On 1/14/2019 at 10:20 PM, ANGEL said:

    RobiBue, you may be able to answer my question please (specific to SCv5)(IPv6 624)

    With V5, do we no longer have to  "cut"

    1st [Received: from PU1APC01HT007.eop-APC01.prod.protection.outlook.com(2603:10a6:800:92::20) blah, blah, blah, Mon, 14 Jan 2019 06:08:02 +0000]


    instead post to parser ENTIRE source data?


    • And, anyone who's game:P may be able to answer:

    if the answer's "yes"; why parsing the entire source data would result in different [Reports sent to] distributions?


    as opposed to parsing modified source data  [Reports sent to] distributions


    Thanks in advance!

    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 (
    [0004]              by PU1APC01HT007.eop-APC01.prod.protection.outlook.com (
    [0005]  Received: from iainternalmeds.com (
    [0006]              by PU1APC01FT052.mail.protection.outlook.com (
    (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 (
    [0006]              by PU1APC01FT052.mail.protection.outlook.com (
    [0003]  Received: from PU1APC01FT052.eop-APC01.prod.protection.outlook.com (
    [0004]              by PU1APC01HT007.eop-APC01.prod.protection.outlook.com (
    [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

  9. 12 hours ago, gnarlymarley said:

    RobiBue, I just tried your tracking URL and it seems to be pointing properly to a leaseweb abuse address.  I think the 5.0 upgrade may have solved this issue.

    Thanks for checking, alas, the reason for the "correct" reporting address is:


    1/15/2019, 3:16:28 PM -0600
    [Note added by x-x-x]
    Route added without comment

    not the new SC version :(

  10. On 1/12/2019 at 5:36 PM, Borgholio said:

    Yes, call me impatient, but I'm excited to find out what changes are coming in Spamcop 5.0.  Anybody have any release notes yet or probably not until tomorrow?

    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 !!!

  11. it might have been, because:

    drum roll please....


    SpamCop v 5.0.0 © 2019 Cisco Systems, Inc. All rights reserved.
    Here is your TRACKING URL - it may be saved for future reference:

    and the gmail IPv6 6to4 WORKS 🤩

    Thank you Cisco! (took a while, but you finally figured it out without compromising the system 😉 )


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

  13. 2 hours ago, ArtmakersWorlds said:

    "described in https://www.cert-in.org.in/SecurityIncident.jsp"   

    Well  get "Requested URL not found."

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

    2 hours ago, ArtmakersWorlds said:

    [...] I have used spamcop for years now.  I've promoted using it to many others. Take the time to send spam through it.  But that's about all the time I care to waste on this.


    Spamcop must be doing SOMETHING though.  It only took a matter of weeks until my sudden flood of spam dwindled down to one a day.

    (That one yesterday and an unrelated "fed ex can't deliver your atm card" bs that also seems to report to nowhere.

    Here in case your interested in this one.  Seems I get that message on a regular basis.

    (Spammers really are a stupid lot aren't they?  An ATM card?  Fed Ex has to deliver something that could fit in an envelope? That I KNOW is not mine?
    Must be enough people even dumber to fall for this and probably have to send someone money first.)


    Confirmation of Spammer's Rules Rule #3: Spammers are stupid, and Spinosa's Corollary: Spammers assume everybody is more stupid than themselves.

    2 hours ago, ArtmakersWorlds said:

    I did once attempt to contact fed ex to see if they have an abuse reporting address.  Apple does, pay pal does, but they do not. 

    (no need to contact them, as it's not from them anyway)

    Kinda drifted off topic but the point is I only got one piece of spam today.   So this site really does work.  Even if I don't understand just how.

    And the email I'm using is one I use everywhere I think it might be harvested.  Survey sites I do, or if I want to bite on what I think is likely a scam, I'll use my trashable email.  So it's out there.  That I'm down to one spam in the morning is fantastic. 

    Maybe I just have to wait until this particular spammer dies of old age before it stops then because I sure don't know what else to do. 

    Thanks for trying though.  But unless someone can post

    1. Do this..

    2. do that...

    I'm out.   Spamcop then delete. Move on.  Life is too short.

    well, all I can say now: it works, and if it works for you , then great 👍:ph34r: mission accomplished!

  14. 1 hour ago, ArtmakersWorlds said:

    Ok, so what is a bit bin???

    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/, 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. 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)

     Tracking URL example

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


  16. Abuse contact for ' -' is 'info[at]fiberserver.net.tr'

    Tracking message source:

    Display data:
    "whois" (Getting contact from whois.arin.net )
       Redirect to ripe
       Display data:
       "whois" (Getting contact from whois.ripe.net)
       Lookup acro14475-ripe@whois.ripe.net
          Display data: <--------------- ? at this link here is the abuse address!
          "whois acro14475-ripe@whois.ripe.net" (Getting contact from whois.ripe.net)
          acro14475-ripe =
       Lookup mu1785-ripe@whois.ripe.net
          Display data:
          "whois mu1785-ripe@whois.ripe.net" (Getting contact from whois.ripe.net)
          mu1785-ripe =
       whois.ripe.net (nothing found)


    No reporting addresses found for, using devnull for tracking.