Jump to content

orenwolf

Members
  • Posts

    4
  • Joined

  • Last visited

orenwolf's Achievements

Newbie

Newbie (1/6)

0

Reputation

  1. To be clear, I don't consider an outage to be a "violation of trust". They happen. I should know, outages fall right in my lap in my day job, as they have now for a decade. *however*, if Cisco has made the *choice* to degrade the performance of sc in order to utilize sc resources within their iron port product (which is how I read their comment on the reporting page), then that *is* a breach of trust, unless I am the only one who would take issue with Cisco saying "Attention, we may arbitrarily degrade the performance of sc (and, presumably, the SCBL) to further our own corporate interests". I personally find that position, if accurate, to be something worth raising debate over, myself.
  2. If a tool breaks, a "we're working on it" usually suffices. After a few more days, some more details or an ETA are usually helpful. Sometimes that isn't possible, but an update at least shows the issue is still of importance and actively considered a problem. After WEEKS, though, with no official statement except the one from Cisco on the reporting page (which, as I've mentioned previously, *seems* to suggest the performance issue is actually being actively caused by decisions Cisco is making with regard to Spamcop.net) is enough to request a more detailed response, and to express displeasure with the lack thereof. Time is not free. Some people have literally put days of their time and effort into Spamcop and the SCBL, and the community has a certain expectation of respect with regards to this effort. In return, we they have trusted Cisco as a shepherd of their donated time and effort. Others have chosen to purchase fuel, essentially to invest in sc itself. They've done this despite sc now being owned by a huge enterprise, again, one assumes as a show of support for sc and the role it plays. So, for the service to have issues for what is quickly approaching one month, and the only official response being "We know, we're using it to make our system better", it's not wrong, in my mind, for people to complain that their gift of time and effort (or, their dollars traded as "fuel") are being squandered, possibly in the name of corporate profit and closed-source, nonpublic solutions. *If* that is indeed what has happened here, I think the volunteers who have put their effort into reporting promptly to sc, and who have voiced frustration in this thread, have all the reason in the world to complain, and to demand answers.
  3. Maybe I'm misreading, but the quote above does NOT sound to me like the "industry-leading anti-spam solution" that Cisco is talking about is sc. The fact that they mention that sc is "is instrumental in collecting message samples for our ongoing investigation" sounds more like sc is a "tool" for assisting in making their solution better. It seems to imply the following: 1: Cisco has a commercial anti spam product (they do, and it isn't spamcop: http://www.cisco.com/web/about/ac49/ac0/ac.../ironport.html) 2: This solution utilizes spamcop for part of how it functions (most likely the spam traps, and to a much lesser extent, user reports) 3: Cisco has decided to sacrifice spamcop performance to increase the performance of their proprietary Ironport solution, apologizing to us spamcop users for this inconvenience. That a lot of analysis for one paragraph of update, but IMHO it's an accurate one. If you consider the financial importance of Ironport devices for cisco over the importance of spamcop.net as a service, it even makes sense. But, as I said in my original post, it still means that we, the sc community, are being deliberately inconvenienced by the shepherd of our community, Cisco, to ensure that their proprietary enterprise product line operates at peak efficiency. That's not a small deal at all. It's a breach of trust with the very community supporting your underlying business, Cisco. Shame.
  4. If I read the reporting page comment correctly, Cisco has identified an increase in spam. In order to process it properly for their own proprietary tools, they are making use of sc resources (one would assume the honeypot addresses), and this use is resulting in slowdowns for "the rest of us". Am I the only one that sees this as a serious breach of trust with the community? Is this not essentially Cisco screwing the community at large to ensure their commercial product is working as efficiently as possible?
×
×
  • Create New...