Jump to content

techie

Members
  • Content Count

    41
  • Joined

  • Last visited

Community Reputation

0 Neutral

About techie

  • Rank
    Member
  1. techie

    SpamCop Access and Performance Issues

    Facepalm.. I can't believe that I didn't notice the 2012 date before.. Several coincidences lined up.. I noticed it pinned at the top of the forum, immediately after I had noted spamcop performance issues, and the date (aside from the year) matched.. Shows how rarely I browse the forum.. It also shows that somebody should clean up the pinned topics..
  2. techie

    SpamCop Access and Performance Issues

    Yep.. I found that one in my archives.. This time around, I have seen no such email, nor have I seen the credit applied to my account.
  3. techie

    SpamCop Access and Performance Issues

    What is the status of this? I have seen no email from Spamcop regarding the credit mentioned above.
  4. techie

    Recent increase in Chinese spam

    I would like to reiterate my suggestion that spamcop should create a new blocklist containing all sites that have non-functional abuse addresses, either because they refuse spamcop reports, pass the reports to the spammer, all addresses bounce, or no addresses can be found. Tag each type separately, and let the users decide if we want to accept them or not. The data already exists in spamcop's database, it just needs to be made available to the end users.
  5. I have made the suggestion several times in the past, but I will make it again. Spamcop obviously knows which sites are refusing spamcop reports, for whatever reason, since they are reporting it as part of the parsing process. I would like to see that data made available as an extension of the spamcop bl. For starters, I would have a class for sites that feed data direct to spammers, or otherwise support spammers, another for sites where all the addresses are bouncing, and another for administrative refusal to accept reports. Use a different return code for each class, so you can decide which sites you want to refuse mail from, and what type of status code you want to return to the sender. I mostly use spamcop as a feedback loop, as I see relatively little spam actually blocked by spamcop. Most is already blocked by one of the other bl's or sanity checks that I use on my server, including a ever growing local blocklist. If I notice a site sending excessive spam, and spamcop shows reports disabled for that site, that site/ip block generally find their way into my local bl in short order. I treat my local bl as a spammer (roach) motel, with infinite capacity, and a write once register. IP blocks check in, and never check out. If the IP range looks like is used for dynamic assignments, then the whole range is added. If the provider appears to be ignoring spam in general, the entire range is added. If the range is assigned to an entity in certain countries, the entire range is entered.. you get the picture.. I block China and Korea on principle, as well of several of the large european ISP's and hosting providers. I also sanity check for valid domain names, and valid and matching reverse DNS.
  6. techie

    Error trying to report held mail

    Yep.. SC appears to be currently broken. I managed to get part of a report page once, but mostly 500 "server error".
  7. I haven't seen "nothing to do" in a while, but I seem to recall it showed up when all possible abuse addresses for a given report were /dev/null'd. If there was a single working address for any section of the report, then you would see the "statistical tracking" message. My sense is that it is a bug.
  8. techie

    Spamcop.net SPF misconfiguration?

    Actually, spam.spamcop.net does have an MX record. It does not have an A record, which is not required. >host spam.spamcop.net spam.spamcop.net mail is handled by 5 vmx.spamcop.net. 184.94.240.88 and .89, on the other hand, have no PTR records. > host 184.94.240.89 Host 89.240.94.184.in-addr.arpa. not found: 3(NXDOMAIN) > host 184.94.240.88 Host 88.240.94.184.in-addr.arpa. not found: 3(NXDOMAIN)
  9. techie

    Spamcop.net SPF misconfiguration?

    I've been seeing the same problem.. It looks like a couple of new servers were put online before DNS was updated. My server has rejected several emails in the last 24 hours from 184.94.240.89 for lack of valid PTR records, leading to the the same bounce warning. Sorry folks, if you don't have a valid PTR record, have mismatched A and PTR records, or have PTR records pointing at invalid domains, my server won't be talking to you. email was sent to deputies[at]spamcop.net early this morning.. no response yet.
  10. My big complaint is the the bounce flag message provides insufficient information to track down the source of the bounce. It lacks, among other things, a timestamp, and the IP address of the server that generated the bounce, both of which make it extremely difficult, if not impossible, to locate the source of the bounce, if in fact a bounce has occurred in the first place. In my case, I have a single server to look at, and have searched the logs going back almost 5 months without locating a single match, or any indication at all that email from spamcop has bounced. I seem to recal that at one point, spamcop glitched, and set the bounce flag based on some extremely stale bounces (ie: the bounces had occurred, but had occurred many months earlier), but I can't find any evidence that I commented on it here, and I can't find any email relating to it.. I might be confusing it with Yahoo groups, but I don't think so.
  11. techie

    IPv6 Routing Support

    In early 2011, when the first IPv6 aware version of spamcop (which simply detected IPv6 headers) was inflicted upon us, I pointed out that the IPv6 detection was in the wrong place. Instead of checking for IPv6 anywhere in the headers, and immediately tossing the report if IPv6 is found anywhere in the headers, it would be just as easy (and would make a lot more sense) to add the IPv6 checking to the parser, and only toss the report if IPv6 is found prior to the point where we can no longer trust the headers, which would eliminate most of the problems that people have been complaining about. Since then, we have had at least two attempted upgrades, both of which failed, and were immediately rolled back. Given that the coders don't seem to be able to get IPv6 working, and have forced us to live with a badly broken (and IMHO easily fixed) system for almost two years, I find it extremely difficult to be optimistic that this "upgrade" will be any better.
  12. techie

    IPv6 Routing Support

    As I posted in http://forum.spamcop.net/forums/index.php?...ost&p=83739 on 12/27/12, I predict that there will be an attempt to upgrade in a couple of months (ie: mid-February), which will fail, followed by another attempt about 6 months later, which will also fail. Given Spamcop's current track record, and the fact that reporting has been puking on IPv6 for no good reason for almost two years, I predict that Spamcop will have working IPv6 support no earlier than March 2014.
  13. I wouldn't hold my breath. I expect that we'll see an attempt in a couple of months, which will fail, and be rolled back for another six months before they try again, which will be yet another failure. Given their current track record, I don't expect SC to have IPv6 working until at least March 2014. After all, SC has been unnecessarily broken with regards to IPv6 for 21 months now, and it needn't have been broken at all for many/most reports. The majority of the current problems with IPv6 reporting could be solved by changing where in the parsing process the IPv6 checking takes place, which I have pointed out several times before.
  14. I have made this suggestion before, but I will make it again.. Since Spamcop has info in the database about abuse addresses that refuse Spamcop reports, and abuse addresses that consistently bounce, it would be nice if that info could be made available as a separate blocklist, so that we can simply reject mail from those sites. If they don't want abuse reports, then I don't want to accept mail from them. Obviously the blocklist should include only those sites that have sent spam, and not sites that have been spamvertized. Currently, as I see those listings go past, I cross-reference them with my spam archive, and if they have repeatedly sent me spam, they get added to my local blocklist. Once they annoy me enough to make it into my local blocklist, they are history, since I almost never remove entries from that list.
  15. techie

    IPv6 Routing Support

    Well, if we also assume two other things, namely that the IPv6 detection code is written as a subroutine, and that the parsing process works on the headers one hop at a time, then the real question is: why did they call the subroutine at the beginning, instead of as a conditional during the parsing process?
×