RobiBue

Oddly enough, I haven’t been getting any amazon/bit.ly spam as of a few days ago. In fact, I haven’t had any spam since Saturday 9th at noon. /me happy/

the info behind the ? in the links is what gives the spammer your info. those are the ones I don't add in the reports ... btw, got the same one today too... recognize the identical bit.ly address...

SC munges the headers (unless it's a ISP that requires full headers) for me when I report the message. usually the message ID looks something like this: Message-Id: <wecW_______________________________________________upLM@vevida.net> the underscore line is placed there by SC. and non-ISP headers are often used by the spammer to trace reported spam and retaliate... that's why I tend to do that. if the ISP wants more info, they can ask for it

although they have your email, doesn't mean that if you report to their ISP that they know whodunit if you munge the name and address. of course, you'd also have to munge the message ID and a few other non-ISP headers that would/could reveal your info... Re: porn spam, amazon has AFAIU pretty strict guidelines and do not tolerate offenders.

Hi klappa, 1) munged headers means that I copy the raw spam (with headers) into notepad (on win) or your editor of choice and change all entries of my email address or part thereof as well as my name into a fake email address and fake name: X-Apparently-To: me@example.com; Sat, 02 Mar 2019 18:48:09 +0000 Received: by mail-it1-f193.google.com with SMTP id d125so1436534ith.1 for <me@example.com>; Sat, 02 Mar 2019 10:48:08 -0800 (PST) To: me@example.com Subject: MY NAME: $15,000 Loan - Pay Back in 3 Years hello MY NAME, we have a loan for you with exorbitant interest. pay it back in three years and we will only charge you 115% interest Turns into: X-Apparently-To: x-x-x-x-x-x@x-xmail.com; Sat, 02 Mar 2019 18:48:09 +0000 Received: by mail-it1-f193.google.com with SMTP id d125so1436534ith.1 for <x-x-x-x-x-x@x-xmail.com>; Sat, 02 Mar 2019 10:48:08 -0800 (PST) To: me@example.com Subject: x-x-x-x-x-x: $15,000 Loan - Pay Back in 3 Years hello x-x-x-x-x-x, we have a loan for you with exorbitant interest. pay it back in three years and we will only charge you 115% interest And then I add the following at the top of the headers: 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. That’s “munging”. 2) alas it’s true that certain links can be “traced” by spammers, the link I started with, had no traceable info. http://se2. mogenromance-svenska. club/ is not traceable let me rephrase that before I get in trouble for making false statements ok, every link you click on, gives the host your IP address, therefore (per se) traceable, but what I mean, is, that it doesn’t give the spammer any clue of your e-mail address. Traceable links, the way I mean it, can be, for instance: http://www.example.com/907743add1337 <- this hex string could be your encoded address http://www.example.com/illgetyou?a=encodedaddresshere If the link already starts like that, then caution is warranted. Since the redirects originated from a “safe” link, the information passed has nothing to do with your info. The links in between can be either reported at the same time or at a later point in time when the spammer is scrambling to get his new site redirected Sometimes I complain to the registrar as well in the hopes that someone there is witty enough to catch the pattern and MO of the spammer.

to Amazon I would writethe following (adding the spam at the end): you are harboring a spamvertised porn site: spamvertised link: http://se2. mogenromance-svenska. club/ redirects as follows: HTTP/1.1 302 Found => Server => nginx Date => Sat, 09 Mar 2019 07:04:17 GMT Content-Type => text/html; charset=utf-8 Content-Length => 75 Connection => close Location => https:// crazytrackings. com/ ?a=100225&c=102723&s1=232 X-Served-By => Namecheap URL Forward HTTP/1.0 302 Found => Cache-Control => private Content-Length => 226 Content-Type => text/html; charset=utf-8 Date => Sat, 09 Mar 2019 07:04:42 GMT Location => https:// cyberblueberry. com/ ?a=100225&c=102723&s1=232&ckmguid=5eaf0d44-97f6-419a-bf50-4dc7daa946ba HTTP/1.0 302 Found => Cache-Control => private Content-Length => 250 Content-Type => text/html; charset=utf-8 Date => Sat, 09 Mar 2019 07:05:03 GMT Location => https:// kewkr. girlstofu**. net/ c/da57dc555e50572d?s1=12951&s2=153430&s3=100225&s5=&click_id=22381729&j1=1&j3=1 P3p => CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT" Set-Cookie => c100916=B0u1wB9CbYmmbLsSFz+i2AKhvFRakvmMJc94KAGrH+9633KgqJ4kxg==; domain=.cyberblueberry.com; expires=Mon, 08-Apr-2019 07:05:04 GMT; path=/; HttpOnly HTTP/1.1 200 OK => Server => nginx Date => Sat, 09 Mar 2019 07:05:24 GMT Content-Type => text/html; charset=UTF-8 Content-Length => 12475 Connection => close Set-Cookie => scriptHash=49415_12951_153430; expires=Mon, 08-Apr-2019 07:05:24 GMT; Max-Age=2592000; path=/; HttpOnly X-Powered-By => PHP/7.0.32 and this last redirect is on IP address Host kewkr. girlstofu**. net (checking ip) = 34.194.20.115 whois -h whois.arin.net 34.194.20.115 ... [...] NetRange: 34.192.0.0 - 34.255.255.255 CIDR: 34.192.0.0/10 NetName: AT-88-Z NetHandle: NET-34-192-0-0-1 Parent: NET34 (NET-34-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Amazon Technologies Inc. (AT-88-Z) RegDate: 2016-09-12 [...] OrgAbuseHandle: AEA8-ARIN OrgAbuseName: Amazon EC2 Abuse OrgAbusePhone: +1-206-266-4064 OrgAbuseEmail: abuse@amazonaws.com OrgAbuseRef: https://rdap.arin.net/registry/entity/AEA8-ARIN [...] I believe this is your IP space. please enforce your AUP. offending message with munged headers follows (and I always munge the headers with my name and address since I send it from a dedicated spam reporting email address which is in name and address different from any other) and see if they say that it's not their IP space

yeah, pretty sure there's money involved. if someone complains they'll probably slap them on their wrist... if too many complain, they'll probably close the account, but the spamvertiser can easily open a new account and start anew...

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

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

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

Does this mean, that I should [refresh/show] every cached whois of every report? thanks for the heads-up

Well, amazonaws spam reports get sent to /dev/null in my case: https://www.spamcop.net/sc?id=z6503507988zf04f1366f6ca8e5a872324eb4f96d690z Tracking message source: 54.180.88.238: Routing details for 54.180.88.238 [refresh/show] Cached whois for 54.180.88.238 : abuse@amazonaws.com Using abuse net on abuse@amazonaws.com abuse net amazonaws.com = abuse@amazonaws.com Using best contacts abuse@amazonaws.com Reports disabled for abuse@amazonaws.com Using abuse#amazonaws.com@devnull.spamcop.net for statistical tracking.

From what I understand, when Julian Haight designed SpamCop, it looked at every possible correctly chained IP address, where it was sent from, and who received it, making sure that spoofed headers would not confuse the chain. If he were still running this system, he would have correctly implemented the 6to4 IPv6 checks, which apparently Cisco/Talos has no intention to do. For them to claim the implementation would cause a security vulnerability is pure BS in my not so humble opinion. It just shows, that their programmers are not as good as one would expect from a company of such security weight. It's an email header parser/analyzer for heavens' sake. And it's broken (on the IPv6 6to4 address side at least.)

I do not believe you mis-spoke. It is an IPv6 problem. SpamCop doesn't resolve the 6to4 private addresses, which are in IPv6 format, and that qualifies as an "IPv6 problem" that we all wish SpamCop would be able to handle "today"

In other words: he probably jinxed it... now someone at outlook will “fix” that “working flaw” 😱

Many times, pasting the spam into a blank notepad first, will take care of those empty lines or will show that there are empty lines. Usually this happens when there is a carriage return (cr) and a line feed (lf) like in unix (cr/lf) and microsoft (cr) receives it...

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.

https://www.spamcop.net/sc?action=rcache;ip=162.252.58.155 netrouting.com claims that it works. Please reset.