Jump to content

techie

Members
  • Posts

    41
  • Joined

  • Last visited

Everything posted by techie

  1. 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. 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. What is the status of this? I have seen no email from Spamcop regarding the credit mentioned above.
  4. 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. 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. 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. 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. 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. 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. 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?
  16. IIRC, the Spamcop update of March 2011 was advertised as providing for future support for IPv6. Immediately after this update, I started receiving bounces for spam containing IPv6 loopback addresses, which had never been rejected prior to this update. I went back through my spam archives, and verified that I had submitted spam containing IPv6 loopback addresses several time during the previous month, none of which had been rejected. My assumption, based on observed Spamcop behavior before and after that update, is that code to detect IPv6 was added during that update, and that instead of using that code to gather data, or as a step-by-step sanity check, it was instead used as a cop-out. My comments on the "right way" and the "wrong way" are based on one assumption about the parsing process, namely that the process works from the recipient back towards the sender. This is the logical method, since Spamcop needs to eliminate hosts within your MX path, so as not to report your receiving server as the spam source, which of course it is not. The host immediately upstream of your receiving server is the last host which can be properly verified, since all headers upstream of that point can be forged. If Spamcop trusts the header upstream of that point, it is only because Spamcop trusts the upstream ISP (such as Yahoo/Google/AOL/etc), and has decided that the internal headers added by those ISP's are trustworthy. Given that the parsing process needs to work backwards, it is logical that sanity check for IPv6 headers should be done at each step in the parsing process, which would eliminate all of the problems with IPv6 loopback addresses in the first hop, forged IPv6 headers, IPv6 tunnels and 6-to-4 gateways prior to the upstream server. This would not eliminate the problems with IPv6 use at the receiving site, or actual IPv6 transit between the receiving server and the host immediately upstream, but it would eliminate the vast majority of the current set of problems, since the spam source would be reached, and parsing terminated, prior to an IPv6 address being encountered. Instead, what I have observed is that the parser looks for IPv6 addresses anywhere in the header as the first step, and pukes if any IPv6 addresses are found, instead of actually attempting to parse the headers in proper sequence, and only puking if an IPv6 address is encountered prior to determining the spam source.
  17. As I said, Why the hell is it advertised on the reporting page?.. If the corporate users don't go to the reporting page, and the twitter account is for the corporate product, then why is the twitter account advertised on the reporting page? It's kind of like advertising a hip-hop nightclub in LA on a classical radio station in Chicago..
  18. If that's the case, then why the hell is it advertised on the SpamCopReporting page?
  19. Update. 2 spam reports that I just submitted went through immediately, but still no sign of anything submitted during the previous 17 hours.
  20. FWIW, none of the spam that I have reported within the last 12+ hours has shown up in the outbound queue. The last spam was processed at 1455 PDT/2155 GMT, or about 6 hours before lisati's report.. So yeah, something is still clogged..
  21. what does this board have against the word "scri_pt"? It inserts a _ in the middle for some stupid reason.
  22. It still broken.. nothing but GW timeouts since yesterday. I know things break, but this is ridiculous. It would be nice if spamcop could back off the 48 hour limit (72 hours would probably be appropriate) until this is fixed, otherwise you're just wasting even more of peoples time than this problem already has. I use a greasemonkey scri_pt to do the reporting, so if reporting is working (even if it's slow, as long as it's not timing out), I can run through the queue without sitting and cursing for hours.
  23. The "Right" way of doing this would have been to add the IPv6 detection code, and have it log to a file for debugging. This doesn't change the existing behavior from the user perspective. The detection code should include checks for the IPv6 loopback address [::1], and treat it the same as 127.0.0.1. The next step would be to add some hooks for each step of the parsing process to call the code, and let it bail out if IPv6 is detected at those points, but you could still do reporting up until the IPv6 handoff, which on all the rejections I have seen, has been on the first or second hop from the sender. It gets more complicated when the receiving site is running IPv6 internally, or if there is actually IPv6 within the path, but most of the rejections I have seen are either the loopback within an Exchange server, or occasionally a internal handoff within the originating site, or a 6to4 gateway within the originating site. You parse as far as you can, and include the IPv6 header in the last report. The wrong way is to simply add a check for IPv6, and puke if found, which is what currently happens, as of the update in March 2011.
  24. Let get a couple things straight.. 1. I can't see the original email that the OP was talking about, so I can't look at the headers to determine if this example is the same as the problem that I reported. 2. There is a distinct difference between understanding why the reports referenced in my complaint are being bounced, and agreeing with the rationale for parsing them in that manner. I understand why the reports are being bounced, and I STRONGLY DISAGREE with the rationale. I suggest that you go back to the other topic, and read my response (post #11), which was essentially my response to the deputies. 3. The response from the deputies stated that the process can't be changed, and my response indicated that I thought that that response was completely bogus. I never received a follow-up response, so NO, I am NOT SATISFIED with the response from the deputies. As far as I can tell, given the lack of follow-up response from the deputies, the problem still exists, and I will continue to complain about the problem when I encounter it until the problem is fixed. Having mailhosts configured, should simply push the date parsing out to the first mailhost in the MX path. Spamcop knows where my MX path begins, and they certainly could change the date parsing to begin at the entry to my MX path, and not several hops upstream of my first MX, in space controlled by an ISP that I AM NOT A CUSTOMER OF, that is not in my MX path, and that I have no reason to trust (and several reasons not to). It's sort of like FedEx or UPS marking a package as having been delivered at the time it arrives at their first sorting center, as opposed to the time it arrives at my door, several days, truck/train/plane rides, and sorting centers later. In case you missed it, I run my own mail servers, and mail is delivered directly to my servers. I'm not running a windows box, and retrieving mail from an ISP using pop3/imap. I'm running multiple unix boxes running sendmail. My ISP (in this case, a university network), provides IP connectivity, but I'm not using their mail servers for inbound mail.
  25. Spamcop has this mistaken concept that certain ISP's are "trusted", and will trust their timestamps, even though the reporting party is not a client of the "trusted" ISP, and the "trusted" ISP may have sat on the spam for an extended period of time before delivering it to the RP's ISP. http://forum.spamcop.net/forums/index.php?showtopic=8850
×
×
  • Create New...