InvisiBill

Members
  • Content count

    50
  • Joined

  • Last visited

Community Reputation

0 Neutral

About InvisiBill

  • Rank
    Member

Contact Methods

  • Website URL
    http://www.invisibill.net/

Profile Information

  • Gender

Recent Profile Visitors

1,013 profile views
  1. I think there was a misunderstanding here. A lot of my comments were general information for anyone who happens to read this thread, nothing against you personally. I am completely agreeing with you that if Cloudflare is proxying material that they have been properly informed violates some law, they need to stop or face the consequences. However, Cloudflare doesn't have access to the original source of the material. I've seen this mentioned in the statements they've made when people have accused them of things before (implying there are a decent number of people who don't understand this), and it's completely true. Just like Google can remove the search results but has no access to the actual website, Cloudflare can remove the proxying functions spreading that website out, but they have no ability to do anything with the original server (since it's someone else's property). I'm not suggesting transactional immunity, I'm just pointing out that Cloudflare can only change things in their own systems, not in their customers' completely independent systems. And just to explicitly state it, the original copy still being there is not a valid excuse for Cloudflare to not terminate their proxying service either. I also wasn't trying to say that you shouldn't attempt a legal fight over this. I was simply pointing out that there are a lot of things that make these cases very difficult to win. The CAN-spam Act was passed 13 years ago. In the first 5 years spam was explicitly illegal, it actually increased 10-fold. I wish more spam and online fraud would get prosecuted, but we seem to have gotten the short end of the stick here. Unfortunately, it's much easier to steal resources and abuse others online than it is to track those people down and make them face the consequences. At least in this case, it's an established business and not some random spammer hiding in a shady country somewhere, so it's a much more solid target. I genuinely wish you luck in this battle, and hope you succeed in stopping blatantly criminal actions. I don't personally have the resources for legal fights, so I just stick to helping people on the technical side of things.
  2. Cloudflare is 100% correct that they don't have any access to the customer's content. They're simply a middleman handing things back and forth. You have just as much access to the original content as they do. However, as a middleman proxying things back and forth, Cloudflare is completely in control of handing that content back and forth through their own systems. That's their entire point of existing. They absolutely cannot be expected to remove the original content, as it's entirely someone else's system. They absolutely should be expected to stop proxying content when notified that it's illegal. Google can't take down the actual sites listed in their search results (because it's someone else's system), but they are expected to remove links from their own system which point to those systems. I see no reason why Cloudflare should be treated any differently. Caveats: You telling them that you don't like something doesn't make it illegal and/or necessary for them to remove it. Laws are complex. Even if there is some allegedly illegal content, there are procedures to be followed in dealing with it. Laws frequently lag behind technology. Even if something is illegal offline (and should be elsewhere according to common sense), it may not be illegal online due to technicalities in laws. The anonymity of the internet, its international nature, and the technological cluelessness of our lawmakers all contribute to making legal fights against these sorts of things very difficult. I'm not in any way qualified to give you legal advice, but I wish you luck in fighting against those who enable spam and other fraud.
  3. No it doesn't. You can find the tracking URL of past reports by viewing the report in your history and clicking the "Parse" link at the top. No, we can't. We need the tracking URL.
  4. On principal, I disagree with that advice. Sure, it's the best way to simply stop getting the spam (when dealing with a well-known entity like this). But spam from a legitimate company is still spam. Simply unsubscribing from spam that you never signed up for reinforces the idea that it's ok to spam people, and the victims can just remove themselves if they don't want it. It shouldn't require work on my part to stop you from abusing my resources and annoying me. If Mailchimp's reputation and ability to deliver emails is important for continued growth, then they need to make sure they're not doing things to give themselves a bad reputation and impact deliverability (like providing spamming services). By reporting any spam they send me, I'm simply calling a spade a spade, no more or less. KNERD, check the email, including the links in the footer as well as in the email headers, for an "abuse" link rather than a plain unsubscribe. It should unsubscribe you as well, while alerting the mailing service that their customer was spamming you.
  5. ICANN itself acts that way. http://www.knujon.com/
  6. In a URL, parameters are the things after the question mark. In your SpamCop tracking URL, it's "id=z6289054704z1ca8c0c6638bb944ad328cf46dd3ee00z". That tells the webpage that the item "id" has a value of "z6289054704z1ca8c0c6638bb944ad328cf46dd3ee00z". When you go to the spamcop.net domain and load the /sc page, it pulls up the report with an ID of "z6289054704z1ca8c0c6638bb944ad328cf46dd3ee00z". Every single tracking URL loads the same /sc page on the webserver, but each one has its own unique ID. Spammers can use this to put an encoded version of your email address or other info into the URLs. That "9020321_hcywgultvlggov_1_track57_57_2_79206" at the end is probably specific to you in some way. SpamCop removes this so that the reported URLs don't give away your identity to the offender. The effectiveness will depend on how tricky the spammer is about disguising your details and how smart SpamCop's algorithms are.
  7. For anyone else who stumbles upon this thread while trying to fix an issue, https://www.spamcop.net/mcgi?action=mhedit is what you're looking for. SpamCop doesn't have any magical powers to know which servers are or aren't "your ISP". It works by sending an email to you directly, and noting which servers are involved when you submit the email back to SpamCop. If anything in your mailflow has changed (including behind the scenes stuff at your ISP), you'll need to redo your mailhost config to make SpamCop aware of the new setup. It's the same thing you had to do when you first set up your SpamCop account, and there's a tab for it at the top of the SpamCop page.
  8. With GMail, you can simply add "+whatever" onto your username to create unlimited, instant aliases. I set up something similar on my mail server hosted at Site5 using filters on the catchall address. Technically these alias emails come in under the catchall, then filters sort them into users' mailboxes. But it still ends up that I can create a "new" email address on the fly and it will end up in my own mailbox. The aliases themselves don't do anything to stop spam, but they make it easy to identify the source and filter it if it becomes a problem.
  9. jazz25 appears to be the spammer here. It seems he registered just to post about this review, and trying to get us to flag it. I don't see how the review is any sort of unsolicited commercial content, therefore it has absolutely nothing to do with spam. The closest I can link this to spam is jazz25's associating this to his business performance. I have no experience with GB Car Deals. I have just as much reason to believe the anonymous reviewer as I do Jazz. If you can get a sworn affidavit from every current and former employee ensuring that they didn't write this, I'll be happy to do what I can to mark it as fake.
  10. The only IP that can be trusted is the one that handed the message to your mail system (since your mail system directly interacted with it). Anything before that could be forged header lines, and can't be trusted. You will see this on nearly every email you submit to SpamCop.
  11. mx1.tb.ukmail.iss.as9143.net bizsmtp Connection rejected. Your IP 17.172.80.97 is in RBL. Please see https://www.spamcop.net/bl.shtml?17.172.80.97 mx1.tb.ukmail.iss.as9143.net has chosen to block your email. They did this despite SpamCop's warning that they shouldn't do so. The rejection notice implies that they made their decision at least partially based on SpamCop's data regarding your mail server's IP, but that IP isn't currently in the SCBL and doesn't appear to have any recent history in it either. Compare it to https://www.spamcop.net/w3m?action=blcheck&ip=43.224.130.72 to see what a listed spammer IP looks like. SpamCop simply makes a list of mail servers that have sent multiple spams to their spamtraps and to their registered users. Many people and organizations make use of that data to help determine if a message is spam or not. Unlike some other RBLs, SpamCop doesn't try to block innocent users in hopes that collateral damage will cause someone to take action. They track actual IPs that have sent multiple spams, and the IPs automatically delist after a little while if they don't send more spam. Personally, that's exactly what I want in an RBL. As precise as possible and self-cleaning as long as the spamming doesn't continue. Unfortunately, shared hosts are prime targets for collateral damage. When you have a thousand people sharing a mail server, one bad person can cause problems for the other 999. The better hosts (like Apple) will take steps to keep spammers from creating accounts in the first place, and remove them quickly when they do get in. But just like living in an apartment complex, sometimes your neighbors will do things that cause issues for you, even if you personally did nothing wrong and the apartment works as quickly as possible to fix the problem. The receiving mail system (assumed to be your father's ISP) is saying that Apple's mail server is the problem. As someone trying to use that server to send mail to their system, they're simply letting you know that they've chosen not to accept your email because they've decided it's spam. They're implying via the link that this decision is based on SpamCop's data about the server, but currently the SCBL doesn't list that IP, and it doesn't look like it has at all recently. Your personal static IP has seemingly nothing to do with this decision (though only the ISP can say for sure). The only reason any of this falls on you is because you want to send an email to your father. You're perfectly free to ignore the error and wait for it to resolve itself (assuming the server ever was listed in the SCBL, it's already been delisted). However, it's in the best interests of your father, as a customer of the ISP, to let them know when their systems aren't working properly. Generally a lack of complaints is interpreted as everything working properly, which tends to lead to things staying the same (or even adding more of the problematic item, since it's assumed to be good). Your father's ISP is the one denying your service. They have come to the conclusion that it's best for them to simply block any mail server that has recently sent spam to a SpamCop user/spamtrap (at least that's what is implied by their rejection notice, though it may not even be accurate). Even SpamCop doesn't think this is a good idea. I guarantee that even if SpamCop were shut down, the ISP would simply find another RBL (probably one less careful than SpamCop) to use for blocking mail. The problem is how the ISP has chosen to deal with incoming mail from potential spammers, not that SpamCop has chosen to make a list of servers that have sent spam. FYI, it looks like they have a history of false positives in trying to block spam coming into these servers. https://www.google.com/search?q=mx1.tb.ukmail.iss.as9143.net
  12. I'm guessing you need to update your mailhost configuration. SpamCop doesn't have any magical powers to know which servers are or aren't "your ISP". It works by sending an email to you directly, and noting which servers are involved. If anything in your mailflow has changed, you'll need to redo your mailhost config to make SpamCop aware of the new setup.
  13. The submitted email for that report has no body. SC's parser needs to have a body to work properly. http://forum.spamcop.net/topic/16745-yahoo-spam-empty-message-spam-in-subject/ is a current thread regarding that limitation, though yours doesn't seem to be the "subject spam" that others are seeing.
  14. I too have seen a huge uptick in spams with a long subject (like 4KB) and no body lately. If this is spammers' latest trick to get around SC reporting, it would be nice if SC could handle that. I like the idea of prompting something to the effect of "No body in email - is that on purpose or did you screw up while submitting it?" I submitted three of them today as attachments to an email, and still got the "missing body" error (so that's not a fix/workaround for the issue). It's rather annoying to have to copy/paste/edit each spam manually.
  15. It might be an issue with how SC is programmed to look the info up. It appears to look up the IP (https://www.spamcop.net/sc?action=showcmd;cmd=whois 194.226.26.13%40whois.ripe.net) to get the contact, which it then looks up for the abuse info (https://www.spamcop.net/sc?action=showcmd;cmd=whois tf2854-ripe%40whois.ripe.net). The abuse info is in the IP result, but not the contact result. It appears SC is walking right past the info it needs.