Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About RJVB

  • Rank
  1. RJVB

    Spamcop cannot find source IP

    Re-read my comment about plugging holes in your ceiling or instead plugging the hole in the plumbing somewhere above your ceiling. Or ponder the Dutch proverb "mopping with the tap open". And BoZz, ++. I also untick inappropriate boxes (unless they'\re going to a SC-internal NULL address). And I have a series of optional boxes to tick or untick for recipients I configured in my preferences that correspond to the sh*t I'm currently getting. But I'm getting very close to the point where I figure out how again one sends spams to SpamCop's auto-reporting address, given the increasingly apparent futility of wasting my time doing manual reports. The spammers have won anyway.
  2. RJVB

    Spamcop cannot find source IP

    Well, it shouldn't be. That's like plugging holes in the ceiling instead of getting the upstairs neighbour to repair the leak in his plumbing. As long as there are things to spamvertise the spam will keep coming. 99.9% of the spam that makes it into my inbox is not of the kind that spamvertises sites on hijacked home computers but of the kind sent by otherwise legit companies who don't have any number of free servers for hosting their site at their disposal and who consider that it's OK to spam anyone of whom they have an address on file. Sadly Spamcop have become more and more lenient with the spam ISPs those companies use, refusing to send reports to what seems a growing minority (and the others including Amazon apparently couldn't care less anyway). And that too many links exploit makes it way too easy to prevent getting reports about links in your spam: just repeat your links a few times (5x seems to be enough already) and you can sleep easy.
  3. RJVB

    Spamcop cannot find source IP

    I've had growing doubts as to SC's usefulness ever since their parsing engine started giving up on spams that contain too many links. Since then, more and more spam seems to have used this trick to avoid the automatic generation of reports to the spamvertised website ISPs. I've been hanging on though, but with just about all my email coming in on GMail I've also wondered why SC don't add a simple parsing rule to work around instead of breaking on the 2002: headers. In the end I wrote a little filter that I added to the chain leading up to SpamAssassin (which handles the SC submission for me), a filter that does the IP6to4 translation described above in the message source. This is what SC should be doing, so it's an IMHO acceptable form of (de)mangling the headers. If anyone is interested in the source (C++) I can upload it here or make it available some other way.