Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by RobiBue

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

  2. 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 :(

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

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


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

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

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

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


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


  10. On 12/12/2018 at 1:19 PM, Lking said:

    If you have an abuse address for these IPs why not report then in "Routing / Report Address Issues" which you have done with other IPs?

    on 12/01/2018:




    On 12/12/2018 at 1:19 PM, Lking said:

    The non-response response you received could well be why spam reports are /dev/nulled


    Tracking details

    Display data:
    "whois" (Getting contact from whois.arin.net )
    Found AbuseEmail in whois search-apnic-not-arin@apnic.net -
    Routing details for
    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

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

  11. for a while now I have been getting some spam from one or more leaseweb customers ([], [], and [].)

    unfortunately, there are (at least) two problems here:

    1. 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.
    2. even if it would look up APNIC, leaseweb would probably end up being /dev/nulled... (see [] )

    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


    Dear Sir/Madam,

    Your abuse notification has been processed and marked as resolved by the Abuse Prevention department, after interrupting the customer services due to non compliance. LeaseWeb therefore considers this issue as concluded. Please note, once the customer informs us that he is willing to resolve the issue, the services will be restored in order for the customer to report a resolution.

    Please keep in mind the nature of the services LeaseWeb provides. LeaseWeb rents servers with an internet connection to customers and resellers. LeaseWeb does not provide the web software, nor does it configure, host or maintain the websites of its customers or of their customer’s customer. LeaseWeb therefore has no dealings with the content on the servers, nor can it remove, add or change that content. The only person who will be able to do this will be the operator of the website.

    Any illicit activities within a particular LeaseWeb company’s network shall be dealt with solely based on received notifications for such separate LeaseWeb company.

    It is important to note that LeaseWeb is the brand name under which various independent and distinct LeaseWeb companies operate. Each of those companies is a separate and distinct corporate entity that provides services in a particular geographic area. Consequently, each separate LeaseWeb company is actually and legally not able to monitor the data its customers store on or communicate through any other LeaseWeb company’s network.

    Notifications therefore must be made to the correct LeaseWeb entity. In case of new information on the facts your notification has been based on, please submit a new notification via the available abuse routes, which are found at: www.leaseweb.com/abuse-prevention

    Thank you for your notification and your co-operation with us.


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

  13. mine reports without problems:


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